> Von: Claus Ibsen [mailto:claus.ib...@gmail.com]
>
> Though I like the idea if we could get some sort of API in Camel
> components that optionally could determine the message size. So we
> could keep track of a size of message data in and out.
>
> Sorta like an activity monitor tool, such as TCP / IO which can show
>
> - packets in
> - packets out
> - data in xxx GB
> - data out xxx GB
>
> Then some components can offer that, for example the file
> consumer/producer could use the java.io.File api to get the file
> length.
>
> The JMS component can just grab the size of the JMS message type
> TextMessage / BytesMessage, and then maybe not support rarely used
> types such as Map / Object messages. And then also traverse the JMS
> properties and grab their length to accumulate that as well.
>
> The TCP / HTTP based components also has access to the total bytes
> in/out of the TCP/HTTP messages.
>
> Then we could have components offer (if they support this)
> - API + JMX API to expose runtime statistics such as number of messages
> + total size
> - enrich each of the created Camel Message with a header with that size
> (so people can use that in their routing, such as CBR etc)
>
>
> There has also been people asking about how to enforce SLA rules, where
> they would need to deny messages that are bigger than X size. So if we
> had a sorta optional API supported by some components then they may be
> easier.
>
> And from management / tooling point of view, we can offer JMX API that
> exposes these stats as well.
>
>
>
>
>
>
> On Fri, Nov 22, 2013 at 9:57 PM, Matt Pavlovich <m...@pavlovich.com>
> wrote:
> > Hello-
> >
> > I opened a ticket to request adding a feature for components to
> provide a Body size to the Exchange that could be used by Simple, or
> set as a header.
> >
> > https://issues.apache.org/jira/browse/CAMEL-6984
> >
> > I see it solving a couple things:
> >
> > 1. Provide throughput metrics
> > 2. Route based on message sizing
> >
> > What does the community think about this? Any suggestions on
> improvements/features or implementation approaches?
> >
> > Thanks,
> > Matt Pavlovich
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
With DataFormat [1] and TypeConverters [2] Camel provides a way for
converting formats into other formats.
Camel-Core could define a new "size" format (value + unit) and provide a
core set of converters. Also it could define the standard header name
(Exchange.SIZE = "CamelMessageSize").
With these you could store the size in a standard header with prebuilt
tools.
Enhancing the DSL could be also an option
from(...)
.storeSize()
.storeSize(differentHeaderName)
.storeSize(customTypeConverter)
.storeSize(differentHeaderName, customTypeConverter)
Just thoughts ...
Jan
[1] http://camel.apache.org/custom-dataformat.html
[2] http://camel.apache.org/type-converter.html
