camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seth Call <sethc...@gmail.com>
Subject Controlling how, and which messages, a JMS Consumer pulls
Date Mon, 04 Oct 2010 20:46:01 GMT
Hi all,

Let me describe my end-goal, and see what you all think:

I have this concept of a 'worker', which is on the consuming end of a
JMS queue. The idea is that I'd like to have many of these workers
deployed.

At the same time, there are different types of work to be done, and a
worker can do 1 or more of these types of work; however, I'd like to
limit it such that a worker can only do 1 thing at once.

So, a worker has capabilities that may or may not mesh with a task,
and workers have a maximum number of concurrent tasks they can do.

It seems to me the right thing to do is to have one queue per
unit-of-work type.  So if you are a worker and support 2 types of
work, then you'd ultimately be listening to two queues. But, once you
started working on one task pulled from one of the queues, it seems
you'd want to dynamically stop listening to the other queue--and
conversely, once the task is done, you'd start listening on that queue
again.  But right away I'm concerned how one could guarantee just one
message is read from either queue at a time.

Another scenario is if no workers are currently available that can
handle a particular type of task because they are all busy, but there
are other things to do in the queue.  So in that case, with the first
message that no one can currently handle, I'd like to put it back on
the queue (or you could say, just never take it off the queue), but
push it back so I can have the available workers look at the next
messages in line.

You can see, though, how eventually there could be an issue if there
were even two items in the queue, and they both are unable to be
processed at the moment because all the workers are busy. With the
reordering of the queue suggestion, you could quickly get into a
situation where the queue is read and thrashed at a high rate unless
something throttles this behavior.

Any suggestions as to what I could look at?  I'm not seeing anything
on the JMS Camel page, or anything in the *Processors that might be of
help, but I'm also concerned I'm going about this the wrong way.

I realize this is a possibly very loaded question and help may not be
forthcoming. But I thought I'd ask.

Regards,
Seth

Mime
View raw message