Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0325B10223 for ; Mon, 30 Sep 2013 20:01:35 +0000 (UTC) Received: (qmail 64023 invoked by uid 500); 30 Sep 2013 20:01:25 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 63968 invoked by uid 500); 30 Sep 2013 20:01:20 -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 63960 invoked by uid 99); 30 Sep 2013 20:01:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Sep 2013 20:01:19 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of baris@acar.org.uk designates 74.125.82.173 as permitted sender) Received: from [74.125.82.173] (HELO mail-we0-f173.google.com) (74.125.82.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Sep 2013 20:01:09 +0000 Received: by mail-we0-f173.google.com with SMTP id w62so6290256wes.32 for ; Mon, 30 Sep 2013 13:00:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=IXJX+ff6j2vqDWIj1v2WHP18uvauKaj4KGi4HiLvGbs=; b=EvLKXV+VrvYY8k5ZcmlD6pJ5eo7CWEsFFsaQ9DAPSzZ7Irf8GqukvDR2naBub282yG bX52ouC7JDsJcIEq37SA3M8whgEB0vggZ206tTPSU3bUkGBrPTVRACm7DDkhjAHhcfiD lXT8R+uRqjElEaG1aeggyYXC8rw3Soae2UQjHoZZqh91zI+yXJ8KgasbJONjzZfXYaaD 4U2XeRVAyIc7iN9IMkKGXDxleE0qol/T5UPckxGulNHaY4OdlrMxzueLZ9fY76U+8IIa EgGEC9Ut+o8m0xGVSbYljNhVgNUmXBX26YSFmmxDFTfR0hRjrK4+e+Nsti7jooC5VEaN Me7A== X-Gm-Message-State: ALoCoQkhL7OFmO1b9TNgUEv8kxt7jFbyJ8eaxb/hdO3jeSAIzzqd6M/uFv9cEEVEUzJZgvrNpmFi X-Received: by 10.194.242.200 with SMTP id ws8mr86852wjc.60.1380571247667; Mon, 30 Sep 2013 13:00:47 -0700 (PDT) Received: from [192.168.1.106] ([141.0.148.53]) by mx.google.com with ESMTPSA id b7sm4242459wiz.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 13:00:46 -0700 (PDT) Subject: Dynamic suspension of JMS producer From: Baris Acar Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (11A465) Message-Id: <1062ECB0-F1B1-48F3-BAFE-81A8A49ACCAF@acar.org.uk> Date: Mon, 30 Sep 2013 21:00:47 +0100 To: users@camel.apache.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Virus-Checked: Checked by ClamAV on apache.org Hi, We have two instances of a service, one for low and one for high priority us= ers. Both post messages to a single shared queue, with the appropriate prior= ity level set so that high priority requests jump in front. If the queue is completely full of low priority requests, it's impossible fo= r high priority requests to arrive. I'd like to prevent this. One way is to limit the number of low priority messages allowed on the queue= . We would like to stop the low priority service posting if the (jms) queue i= s >90% full. This always leaves some headroom on the queue for some high pri= ority messages. We've had success with this model in other (non-camel) appli= cations. How best could I do this with Camel? Also very open to completely alternativ= e proposals solving the use case.=20 I don't think that there is a JMS-only way to inspect queue depth - we'll ha= ve to use vendor-specific code to interrogate queue depth (we use IBM MQ and= Solace). The first ideas I had were: - use a RoutePolicy to suspend the part of the route that's posting - but ca= sual playing found that suspending in this way caused exceptions rather than= blocking behaviour when a route was suspended (I might be doing something w= rong). - write a processor which sits just before the "jms:..." endpoint, which ins= pects the queue and blocks as appropriate. This seems a bit ugly (it needs t= o know about specific downstream endpoints, which is "weird").=20 Is there something more Camel-y? Any thoughts or ideas most welcome.=20 Bar=C4=B1=C5=9F=