[ https://issues.apache.org/activemq/browse/CAMEL-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-2206. -------------------------------- Resolution: Fixed Fix Version/s: (was: 2.2.0) 2.1.0 trunk: 883614. Thanks a lot for the contribution Stephen. I have committed it and create a wiki page http://cwiki.apache.org/confluence/display/CAMEL/Sampling When you have the ICLA in place you will be able to edit the documentations as well. In the mean time feel free to comment/feedback the current wiki page. > Addition of 'Sample' Throttling strategy > ---------------------------------------- > > Key: CAMEL-2206 > URL: https://issues.apache.org/activemq/browse/CAMEL-2206 > Project: Apache Camel > Issue Type: New Feature > Components: camel-core, camel-spring > Reporter: Stephen Gargan > Assignee: Claus Ibsen > Fix For: 2.1.0 > > Attachments: sampling-patch-core-with-javadoc.txt, > sampling-patch-core-with-stats.txt, sampling-patch-core.txt, > sampling-patch-core.txt, sampling-patch-spring.txt > > > I've been using a different kind of sampling based throttling pattern > recently and figured others might find it useful. The basic premise is the > same as the current throttler, there is a consumer downstream that has > specific requirements as to how fast it can process incoming exchanges and a > mechanism is required to 'throttle' the exchanges inbound to it. The > difference between the current throttler implementation and the sampling > throttler is that where the current throttler queues up all the exchanges it > receives, the sampling throttler will allow only a single exchange through > for a period and 'drop' all others; dropped exchanges being passed to a stop > processor to complete them. > Its been useful for situations where a route receives many semantically > equivalent exchanges in a time period, any single one of which could be used > to represent them all. For example, say an upstream component generates a > stream of warning alarms and sends these to an email processor to inform the > operator. An email for each alarm would be overkill instead one every x > minutes or so would be preferred. Also it would be undesirable for the > throttler to queue up these warning alarms as when the upstream component > ceases sending them the emails should cease. Sampling the warnings would pick > one for each x minute period, and stop the rest. > This would be defined via the java dsl as follows > {code}from("direct:alarm-notifier").sample(60, > TimeUnit.SECONDS).to("direct:alarm-emailer"){code} > or > {code}from("direct:alarm-notifier").sample().samplePeriod(1).timeUnits(TimeUnit.SECONDS).to("direct:alarm-emailer"){code} > or with a default of one per second > {code}from("direct:alarm-notifier").sample().to("direct:alarm-emailer"){code} > In spring xml it looks like > {code} > <route> > <from uri="direct:sample" /> > <sample> > <to uri="mock:result" /> > </sample> > </route> > {code} > or > {code} > <route> > <from uri="direct:sample" /> > <sample samplePeriod="1" units="seconds"> > <to uri="mock:result" /> > </sample> > </route> > {code} > If this patch is accepted, I'd be happy to update the wiki with the required > documentation. As per ususal I've split the patches, one for core and one for > spring -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.