camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seth Call <>
Subject Re: Controlling how, and which messages, a JMS Consumer pulls
Date Mon, 04 Oct 2010 20:52:22 GMT
And then I find the Dead Letter Channel.   It seems that perhaps, with
this mechanism, it might make sense to just reject the message once I
started a unit of work (or if I find the current worker that pulled
the task can't handle it), and let the routing re-route to the next
worker in line.

Not sure yet.  I'll definitely dig into the DLC  as much as I can go.

On Mon, Oct 4, 2010 at 3:46 PM, Seth Call <> wrote:
> 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

View raw message