Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 17897 invoked from network); 4 Oct 2010 20:46:30 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Oct 2010 20:46:30 -0000 Received: (qmail 55912 invoked by uid 500); 4 Oct 2010 20:46:29 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 55863 invoked by uid 500); 4 Oct 2010 20:46:29 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 55855 invoked by uid 99); 4 Oct 2010 20:46:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Oct 2010 20:46:29 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sethcall@gmail.com designates 74.125.83.45 as permitted sender) Received: from [74.125.83.45] (HELO mail-gw0-f45.google.com) (74.125.83.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Oct 2010 20:46:22 +0000 Received: by gwb11 with SMTP id 11so1771487gwb.32 for ; Mon, 04 Oct 2010 13:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=WIdWpwy+JVxBBY8W6r9RcyPmwtftMEO8KCGuPFGOhbE=; b=VR3+BlZFw0YM3deAF0IQ4pe9I34lYQ36vflHTsiCY8cegHDApIIzu0nFgE2ffjgJZm 7qrHl20nWEFnXNKMs3FeCe19zDh324YRnRUYxYpbpcV2m+U1Gez6+suPwvV9sqK12MWb uHEgtoIwhHtQODpRCBfYAkfibeM+8Fk9WLOv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XtsjRp+YfYAKv/ve+6D4qQWg65kXGJ+uBThsZkYYORyFMUP+O35q3tKyrHAetbaII/ /rhEM1v98DM3btp5UGyXn6gRSBDdfQCnpoBxYRSff5Udqao72mLVNQ3ysSx6qb2h7O5p QEkJPV3IzJuZ9/xAKkjtrx3s2vJt3T3QazsT0= MIME-Version: 1.0 Received: by 10.90.115.14 with SMTP id n14mr5021873agc.77.1286225161821; Mon, 04 Oct 2010 13:46:01 -0700 (PDT) Received: by 10.150.59.7 with HTTP; Mon, 4 Oct 2010 13:46:01 -0700 (PDT) Date: Mon, 4 Oct 2010 15:46:01 -0500 Message-ID: Subject: Controlling how, and which messages, a JMS Consumer pulls From: Seth Call To: users@camel.apache.org Content-Type: text/plain; charset=ISO-8859-1 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