Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <5489D183.3050509@pocock.pro>
Date: Thu, 11 Dec 2014 18:16:51 +0100
From: Daniel Pocock <daniel@pocock.pro>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.7.0
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: Throttling based on content in camel
References: <1418230393897-5760505.post@n5.nabble.com>
 <etPan.548985ec.2ae8944a.16c@localhost>
 <1418312309397-5760581.post@n5.nabble.com>
In-Reply-To: <1418312309397-5760581.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


On 11/12/14 16:38, yogu13 wrote:
> Hello Williem,
> 
> We would like a lock to be implemented instead of any async delay as the
> requirement is to allow X number of  processing threads to be allowed for a
> particular customer at any given point in time. If the number of requests
> exceed X then the spilled ones needs to be blocked till any one of the
> ongoing threads/flows ends the processing. Also the blocked threads would be
> blocked for a finite time exceeding which they would be returned back.
> 

Are you looking for throttling or can your requirement simply be met by
putting a limit on the number of threads active at one time?

I recently looked at the async feature of the Throttler component and I
was concerned that it was not clear in the documentation whether
messages processed asynchronously after a delay would still be processed
within the transaction.  One consequence if they are not processed
within a transaction is that if the JVM stops abruptly while some
messages are delayed then the messages waiting in RAM for asynchronous
processing could be lost.

One way to deal with this is to put the messages back into the message
broker with a scheduled delivery header.  The message broker is then
responsible for persistence.