Reusing channel in message handler function

43 views
Skip to first unread message

Nuttanart Pornprasitsakul

unread,
Jul 22, 2015, 5:14:36 AM7/22/15
to clojure-rabbitmq
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. Below are the variation of the codes I've tried.

(lc/subscribe channel "source" (fn [ch meta message]
                                     (lb/publish ch "" "destination" (str message))
                                     (lb/ack ch (:delivery-tag meta))))

and

(let [conn (connect)
        channel (lch/open conn)
        channel2 (lch/open conn)]
    (lq/declare channel "destination")
    (lc/subscribe channel "source" (fn [ch meta message]
                                     (lb/publish channel2 "" "destination" (str message))
                                     (lb/ack ch (:delivery-tag meta)))))

I wonder if these two approaches are safe to use?

Thanks,

- Tap

Michael Klishin

unread,
Jul 22, 2015, 9:58:24 PM7/22/15
to clojure-rabbitmq, visib...@gmail.com, visib...@gmail.com
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

Nuttanart Pornprasitsakul

unread,
Jul 22, 2015, 10:30:26 PM7/22/15
to clojure-rabbitmq, mkli...@pivotal.io
Got it. I think we'll go with you suggestion and never mind about the issue. Thanks for looking at these in your busy week!

-Tap
Reply all
Reply to author
Forward
0 new messages