Possible race condition?

[parhs]

I tried doing several RPC calls using channel.basic_consume to 'amq.rabbitmq.reply-to'.
However since channels are pooled I am facing an issue when doing basic_cancel after I get the response.
basic_cancel calls work_pool.shutdown(true)
The problem seems to be here. I guess the problem is that few calls stuck here since shutdown_conditional.signal may occur before shutdown_conditional.wait, so I have to wait 60s for the timeout.

bunny/lib/bunny/consumer_work_pool.rb

Line 73 in 6f8c1b0

@shutdown_conditional.wait(@shutdown_mutex, @shutdown_timeout)

I do not get errors but the problem is performance related. I cant think of any workaround currently.

[michaelklishin]

You cannot concurrently use Direct Reply-To on a shared channel. Channels must not be shared between threads.

On the RabbitMQ side, Direct Reply-To is a convention and a bit of shared channel state that does not
assume concurrent access.

[parhs]

Only a single thread has access to the channel since connection_pool is used so it isn't "shared". The problem is that it waits for consumer_work_pool shutdown.

I tried an alternative solution to pool RPC clients each one with its own channel and they do not need to be shutdown. It works very fast.
Probably subscribing and unsubscribing every time isn't very efficient.

I am guessing that @shutdown_conditional.signal is called before @shutdown_conditional.wait under some circumstances

I haven't tested yet it but @shutdown_conditional.wait(@shutdown_mutex, @shutdown_timeout) if busy? might work, since there is a similar check at .signal

[parhs]

@shutdown_conditional.wait(@shutdown_mutex, @shutdown_timeout) if busy?

This seems to work for me. I am not sure if it 100% safe though