[
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.
