camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel Runtime Management : Exchange Load
Date Mon, 22 Aug 2011 08:27:07 GMT
On Sun, Aug 21, 2011 at 10:26 PM, christian.ohr
<> wrote:
> Hi,
> I consider runtime monitoring and manageability as one of the key features
> for any real-world usage of "headless" integration solutions. Camel has good
> JMX support (and improving), but the exposed attributes may not always be as
> usable as possible. Often it's only about details, e.g. min/max/avg
> processing time should omit at least the first exchange - usually there's
> extra initialization cost that is not representative for all subsequent
> exchanges and distorts the statistic to some degree.
> At this time I'd like to propose an additional runtime attribute: an
> exchange load. It can be seen as an equivalent to the Unix process load
> (obtained e.g. with the "w" command) and is an EWMA (exponentially weighted
> moving average) of the inflight exchanges of each individual route or the
> whole Camel context. It averages the number of exchanges over a certain
> period of time (e.g. 1, 5, 15 minutes), giving bigger weight to more recent
> readings, and smaller weight to older readings. At any time, you would get a
> good impression about how loaded the Camel machinery has recently been.
> If this seems useful, I'm happy to open a JIRA issue and provide a patch
> that adds this statistic.

Well it sounds at first like a good idea, but then maybe not.

Camel provides basic information which is fast and easy to calculate
on the fly, without any contention points etc.

Very often any capable monitoring tooling is able to provide you with
loads of such kind of details based on the stats it can extract from
Camel over JMX. And they allow you to customize your dashboard and
what kind of details you want.

For example tooling such as: Nagios, Hyperic, FuseHQ and from the
bigger vendors as well.

So I am just a bit concerned that Camel does not cross the line and
starts to provide stats which people ought to get from a management
And if this new load stat is added, then people might want to be able
fully customize the stat according to their needs. By which the
management tool already offers such insights. So I am just a bit
cautions to now move down a path where Camel should not go.

As we love contributions, and that a "load" stat would be nice to
have, then I am sure to go for it Christian. And its easier to discuss
when there is some code at hand to look at as well.

> cheers
> Christian
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message