+1 to create a new ThrottlingContentBasedRoutePolicy, and we can do some refactoring to let ThrottlingContentBasedRoutePolicy and ThrottlingInflightRoutePolicy share some common logic in a super class.
-- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On December 11, 2014 at 11:40:19 PM, yogu13 (yogesh....@synechron.com) 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. > > On quick inspection of the current > org.apache.camel.impl.ThrottlingInflightRoutePolicy i see that instead of > boolean stop = maxInflightExchanges > 0 && size > maxInflightExchanges; > within throttle method if we can externalize the condition for user defined > implementation to return the value then it could do.. > > Also to maintain backward compatibility it would be better if a second > implementation of org.apache.camel.impl.ContentBasedRoutePolicy is made > available. > > However this is just the initial thought ... > > Let me know if you see any issues with this to begin with and would this be > desired ? > > Regards, > -Yogesh > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Throttling-based-on-content-in-camel-tp5760505p5760581.html > > Sent from the Camel - Users mailing list archive at Nabble.com. >
