camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-8999) Watchdog route policy for spotting starved, overactive or stuck routes
Date Wed, 22 Jul 2015 12:16:05 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636790#comment-14636790
] 

ASF GitHub Bot commented on CAMEL-8999:
---------------------------------------

GitHub user yuruki opened a pull request:

    https://github.com/apache/camel/pull/567

    CAMEL-8999 Watchdog route policy

    Watchdog route policy for spotting starved, overactive or stuck routes.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/yuruki/camel camel-watchdog

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/camel/pull/567.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #567
    
----
commit 95f5f49289cb29e46c185a017541fa40f1d08a1c
Author: Jyrki Ruuskanen <yuruki@kotikone.fi>
Date:   2015-07-22T12:11:04Z

    Added WatchdogRoutePolicy

----


> Watchdog route policy for spotting starved, overactive or stuck routes
> ----------------------------------------------------------------------
>
>                 Key: CAMEL-8999
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8999
>             Project: Camel
>          Issue Type: New Feature
>            Reporter: Jyrki Ruuskanen
>            Priority: Minor
>
> In our use case we need to spot routes that are processing less than expected or too
many exchanges in a certain time. The limits also depend on whether it is a busy or a quiet
time (day vs night, weekdays vs weekend etc.).
> Also, we would like to be able to spot routes that are stuck but produce no errors.
> In my opinion the most natural solution is a RoutePolicy that would keep count of inflight
and completed exchanges and perform periodic checks on this information. Multiple checks with
different schedules would be allowed per RoutePolicy instance.
> If a check fails the RoutePolicy would log a warning. These warnings could then be singled
out based on the logger by, for example, an automated log watcher.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message