concurrent-consumers in context to spring integration

Hi,

I just have one query regrading the jms message driven channel adapter , jms message driven channel adapter adapter is used to take the data from queue and put it into some destination ,in context to spring integration my destination is another channel....below the sample code is ....

Code:

---

<jms:message-driven-channel-adapter
                        id="mq-message-listner" channel="aggregator-input-channel"
                        destination-name="${queueName}" concurrent-consumers="${concurrent-consumers}" />

---

it is taking properties from separate properties file ...below is the properties file...

Code:

---

queueName=RODS.APP.DATA.IN2
concurrent-consumers=10
queueCapacity=100

---

Now my query is what is meant by concurrent-consumers here ..please explain..!!:rolleyes:

It specifies how many threads will be used to consume messages from the queue. If it's 1, only one message will be processed at a time, the next message won't be consumed until either the flow completes, or an asynch hand-off occurs.

If greater than 1 then multiple messages can be processed at the same time (concurrently); note that it is possible for messages to be processed out of sequence in this case.

Quote:

---

Originally Posted by Gary Russell

It specifies how many threads will be used to consume messages from the queue. If it's 1, only one message will be processed at a time, the next message won't be consumed until either the flow completes, or an asynch hand-off occurs.

If greater than 1 then multiple messages can be processed at the same time (concurrently); note that it is possible for messages to be processed out of sequence in this case.

---

Hi,
Thanks a lot for the explanation could you please specify the line that you have quoted that is....

Quote:

---

note that it is possible for messages to be processed out of sequence in this case.

---

please explain it ..as I am not able to grasp this one..!!:confused:

Let's say message 1 is complicated, and takes 10 seconds to process.

Message 2 takes 5 seconds to process and messages 3 and 4 take 1 second to process each.

Now, let's say you have concurrent consumers set to 3.

This means that messages 1, 2, and 3 will all start at around the same time, let's call it "t".

Message 3 will finish at t+1 and the thread that processed it is now available to process the next message so, message 4 will start at around t+1, and complete at around t+2, message 2 will complete at t+5 and message 1 will complete at t+10.

If the ultimate consumer of your flow is another JMS queue, then these messages will likely be inserted in the output queue in this order: 3, 4, 2, 1.

Note that, even if the messages all take approximately the same time to process, the output order is indeterminate because of the way the hardware and operating system schedules work.

If you need to maintain the sequence of messages arriving on a queue, you can only use one thread but, of course, it will take longer overall to process the messages. In the above scenario, with one thread, it will take 10+5+1+1 = 17 seconds to process the 4 messages. With 2 or more concurrent consumers, it will only take 10 seconds.

Quote:

---

Originally Posted by Gary Russell

Let's say message 1 is complicated, and takes 10 seconds to process.

Message 2 takes 5 seconds to process and messages 3 and 4 take 1 second to process each.

Now, let's say you have concurrent consumers set to 3.

This means that messages 1, 2, and 3 will all start at around the same time, let's call it "t".

Message 3 will finish at t+1 and the thread that processed it is now available to process the next message so, message 4 will start at around t+1, and complete at around t+2, message 2 will complete at t+5 and message 1 will complete at t+10.

If the ultimate consumer of your flow is another JMS queue, then these messages will likely be inserted in the output queue in this order: 3, 4, 2, 1.

Note that, even if the messages all take approximately the same time to process, the output order is indeterminate because of the way the hardware and operating system schedules work.

If you need to maintain the sequence of messages arriving on a queue, you can only use one thread but, of course, it will take longer overall to process the messages. In the above scenario, with one thread, it will take 10+5+1+1 = 17 seconds to process the 4 messages. With 2 or more concurrent consumers, it will only take 10 seconds.

---

Hi Gary,

NICE explanation, one thing I wanted to clarify that you have provided the expnation in which you have guided that...

Quote:

---

Note that, even if the messages all take approximately the same time to process, the output order is indeterminate because of the way the hardware and operating system schedules work.

If you need to maintain the sequence of messages arriving on a queue, you can only use one thread but, of course, it will take longer overall to process the messages. In the above scenario, with one thread, it will take 10+5+1+1 = 17 seconds to process the 4 messages. With 2 or more concurrent consumers, it will only take 10 seconds.

---

wat about if I have 4 concurrent consumers in this case will it make the process more faster...I mean to say how we will decide how many numbers of concurrent consumers will best fit in the situation...? :confused:

Trial and error (testing).

There is no way to provide a simple answer; it depends on too many factors.

This is nothing to do with Spring Integration - it applies to any multi-threaded application. With experience, you'll know how to come up with a good starting point, but you'll still have to do some tuning.

thanks Gary ...yeah I will do that...!!and in the logs I have to check out the time...!!