camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Gargan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CAMEL-2206) Addition of 'Sample' Throttling strategy
Date Fri, 20 Nov 2009 02:59:52 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stephen Gargan updated CAMEL-2206:
----------------------------------

    Attachment: sampling-patch-spring.txt
                sampling-patch-core.txt

> Addition of 'Sample' Throttling strategy
> ----------------------------------------
>
>                 Key: CAMEL-2206
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-2206
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core, camel-spring
>    Affects Versions: 2.1.0
>            Reporter: Stephen Gargan
>            Priority: Minor
>         Attachments: 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.


Mime
View raw message