Announcement Announcement Module
No announcement yet.
Single threaded vs multiple thread Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Single threaded vs multiple thread

    Hi Guys,

    i have one small question for you. If we pass data through Queue channel, then receiver will operate on a separate thread because it requires pooling and it will be asynchronous. But if we use Direct channel which is also a publish/subscribe channel and also has point-to-point semantics , receiver will be operate on sender's thread (single thread), hence synchronous.

    but if we have publish/subscriber channel and if there are muliple consumers, will all the consumers operate on sender's thread?


  • #2
    Yes; each consumer will be called serially on the caller's thread. You can affect the order they are called by adding an 'order' attribute to the subscribers.

    You can make the calls asynchronous, by adding a task-exececutor attribute to the publish-subscribe-channel.


    • #3
      Also to clarify some terminology, when you said "Direct channel which is also a publish/subscribe channel and also has point-to-point semantics", that sounds a bit confused given the way we use the EIP terminology. Basically a channel is either publish/subscribe OR point-to-point, never both. See these 2 pages for a quick overview of the EIP usage of those terms:

      The difference between Direct channel and Queue channel is exactly as you stated though: a Queue channel buffers messages, thereby requiring explicit receive calls (usually from a different thread) while a Direct channel invokes a subscribed handler *directly* within the same Thread that calls the send() method.


      • #4
        Sorry, yes @kelumt, I misread your post. My reply relates to the <publish-subscribe-channel/>.

        If you have multiple subscribers to a DirectChannel, they will be serviced in round-robin fashion, with each message going to only one subscriber.


        • #5
          Hi Gary, Mark,

          Really thanks for your great comments. actually it was a great leaning curve for me.

          @Gary, you came with another good thing about publish/subscribe channel, i thought since it has more than one subscriber, each subscriber operates on separate thread.

          But as a general idea, does subscriber needs to wait for his turn? I thought all the subscribers will notify at the same time and they will start at the same time. what do think about this



          • #6
            No, the default is to send the message to each subscriber in turn and the same thread. If a subscriber has some async handoff downstream (e.g. a queue channel), then when the current thread returns to the channel, the message will go to the next subscriber. The thread will only return to the caller after all the subscribers are done with the message.

            If you add a task-executor to the <publish-subscribe/> channel, then the async handoff is done internally by the channel and the calling thread returns.The amount of concurrency depends on the characteristics of the task-executor.

            For example, if there are 5 subscribers and the task-executor only has a pool-size of 2, then the 5 requests will immediately be scheduled (and the calling thread will return), but only 2 of the subscribers will get the message immediately; the third subscriber will get the message after one of the first two completes its work, etc, etc.

            Hope that helps.


            • #7
              @Gary, thanks fir nice explanation. So now i need to move from threads to transactions. Currently I am doing R&D on spring integration and we are going to modify/ rewrite our existing legacy web application using Spring integration and there is a requirement to connect with external applications as well.

              Current legacy system consists of highly coupled modules and our first step to re-factor those modules into low coupling individual units and use the spring integration whenever possible. But one problem came across is how to handle cross module transactions?
              Our system has transactions which starts from one module and ends with another. Since all these modules are in same application context, we use spring jdbc transaction management to handle transactions. But if we introduce messaging how can we preserve the transaction functionality.

              I found there is a concept called error channel and can we direct any exception to that channel and do roll back kind of thing for spring transactions?



              • #8
                As long as you use only DirectChannels (or pub-sub without a task-executor), all components in the flow will be invoked on the same thread, and transactions will work, just like in your current application.