On Wednesday, July 22, 2015 at 12:14:36 PM UTC+3, Nuttanart Pornprasitsakul wrote:
Hi,
This question is related to
blocking issue that I'm asking, but I think better separating this to prevent putting more noises in that issue. I started to think that the issue that happens to me causes by opening and closing channel to often in the subscribe handler function (the snippet below extracted from
here)
(lc/subscribe channel "source" (fn [ch meta message]
(let [pub-ch (lch/open conn)]
(lb/publish pub-ch "" "destination" (str message))
(lch/close pub-ch))
(lb/ack ch (:delivery-tag meta))))
The reason I keep doing it this way is because in the
Java RabbitMQ client Channel documentation says that a channel shouldn't be shared between threads. As my understanding, message handler function can be executed in multiple threads that's why I create a new channel and close it within the handler function. But from my other test results, it seems like sharing channel between threads making handler function run a lot faster and importantly, blocking issue doesn't happen.
You can reuse the channel in this particular case. Yes, consumer methods will be executed in a thread pool but
per-channel ordering is guaranteed by the Java client (ConsumerWorkService, in case you wonder). I didn't
realise you were closing and opening channels inside a delivery handler. That should not be necessary and sounds
more dangerous than technically having channel sharing ;)
Thread sharing is a no-go if you intend to publish on a channel concurrently. As I explained in above,
Java client will effectively make publishing sequential in your case.
If this solves the blocking issue for you, I'd simply recommend you publish responses on the same
channel your deliveries are on (this is why the callback has `ch` as the first argument!) and move on :)
MK