Thanks David for the suggestion, but the documentation says that this
option is for concurrently handling replies. I am looking to
concurrently handle requests. Regardless of the documentation, I just
gave this a try and it does not fix the issue.
Thanks again,
Jim
On 2/6/2012 10:01 AM, David Karlsen wrote:
Read the section on "Request-reply over JMS" - you're looking for the
threads option.
2012/2/6 Jim Newsham<[email protected]>:
Hi Ngoc Hai,
I'm not talking at all about the producer side where replies are processed,
but the consumer side where requests are being received and processed.
Incoming requests are not being dispatched to idle threads; instead, they
are backing up behind a single (non-idle) thread.
To me, this looks like a bug. I am interested in hearing the opinions of
the community on this point, and I'm willing to file a JIRA issue.
Thanks,
Jim
On 2/3/2012 6:32 PM, Pham Ngoc Hai wrote:
Hi Jim,
Since it's InOut queue, the reply is processed by a single thread as
stated in here: http://camel.apache.org/jms.html no matter how many
concurrentConsumer you set.
Regards,
Ngoc Hai.
________________________________
From: Jim Newsham<[email protected]>
To: [email protected]
Sent: Saturday, February 4, 2012 10:55 AM
Subject: jms concurrentConsumers is not competing consumers
We are using Camel 2.9.0. We are using the "concurrentConsumers=n" option
on our jms consumer endpoint so that we can handle numerous InOut requests
concurrently. In Camel documentation, this option is described as
supporting competing consumers, which I interpret to mean a pool of threads
which are _competing_ to handle incoming requests. I expect that whenever a
request comes in, that request will be processed by some idle thread from
the thread pool (if there are any). However, this is not that behavior we
are observing. Instead, I observe some requests not being processed
immediately (or for quite some time), despite having numerous idle consumer
threads, and this is causing a severe liveness issue for our application.
Let me describe a simple scenario. Assume we have a single InOut jms
queue with concurrentConsumers=3, and the following stream of messages (and
required processing time):
Message #0 - 1h
Message #1 - 1s
Message #2 - 1s
Message #3 - 1s
Message #4 - 1s
Message #5 - 1s
Message #6 - 1s
Message #7 - 1s
Message #8 - 1s
Message #9 - 1s
Message #10 - 1s
Because Message #0 requires 1 hour to process, it will occupy one
concurrent consumer thread for 1 hour. Nevertheless, we expect the
remaining 2 threads should be able to handle the remaining 9 messages very
quickly. Instead, messages #3, #6, #9 are not processed until Message #0
completes processing -- an hour later. Based on this observation, it
appears that messages are dispatched to queues owned by individual threads,
in round-robin fashion, instead of having threads compete to consume
messages from a single queue. When some messages can take a long time to
process, it can mean that messages can queue up and go unprocessed for a
very long time, even when there are free threads.
As you can see, this is not "competing consumers". Is the above behavior
considered a bug? Are there any suggested workarounds?
Thanks!
Jim
