[
https://issues.apache.org/activemq/browse/CAMEL-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55661#action_55661
]
Claus Ibsen commented on CAMEL-2206:
------------------------------------
I wonder if the DEBUG logging for skipped Exchange should be TRACE level.
Then it wont spam logs for high throughputs and you run with DEBUG logging.
And the Exchange that is picked up as sample you could log how many was skipped
in that period
For example the log could be a DEBUG level something like:
Sampling exchange out of XXX in the last XXX units
> 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
> Affects Versions: 2.1.0
> Reporter: Stephen Gargan
> Priority: Minor
> Fix For: 2.1.0, 2.2.0
>
> Attachments: sampling-patch-core-with-javadoc.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.
