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.
