You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Henrique Viecili <vi...@gmail.com> on 2014/04/14 05:57:21 UTC
StreamCache exausted after type conversion in EventNotifiers
I've just faced an interesting issue with a StreamCache body being
'exausted' after calling exchange.getIn().getBody(String.class) inside an
EventNotifier
I'm using Camel 2.10.0 (inside JBoss Fuse 6.0) and captured an
ExchangeCreatedEvent on a HTTP endpoint (input). The payload was an
instance of InputStreamCache and after the EventNotifier executed I got a
'Premature End of File' trying to parse the body as xml in the pipeline.
Looking at the source code of InputStreamCache (extends
ByteArrayInputStream) the writeTo method uses IOHelper.copy which
'consumes' the underlying byte array, so a next call would throw some
IOException. I reckon this behaviour is correct according to the interface
StreamCache.
What I wonder is whether the automatic TypeConversion should (or not) try
to reset() the StreamCache after doing the type conversion, avoiding such
situations.
Does this make sense? Is this fixed in the latest versions or I should
raise a JIRA?
Regards,
Henrique Viecili
Re: StreamCache exausted after type conversion in EventNotifiers
Posted by Henrique Viecili <vi...@gmail.com>.
Thanks for the reply guys, once I finish the route/unit tests I will try
with the latest versions.
I ended up creating a utility method to reset the StreamCache when
obtaining the body in our custom EventNotifier and InterceptStrategy.
The route is quite simple:
<route>
<from uri="servlet:///myService" />
<to uri="bean:myTransformerBean?method=transformRequest" />
...
</route>
The EventNotifier is called for ExchangeCreatedEvent on
"servlet:///myService" and instead of using
exchange.getIn().getBody(String.class) I've created the utility methods:
(Groovy-ish)
static String getBodyAsString(Exchange exchange) {
String result
Object body = exchange.getIn().getBody()
if (body) {
if (body instanceof StreamCache) {
String charset = exchange.getProperty(Exchange.CHARSET_NAME, "UTF-8")
result = readStreamCache(body, charset)
} else {
result = exchange.getIn().getBody(String.class)
}
}
}
static String readStreamCache(StreamCache stream, String charsetName) {
ByteArrayOutputStream baos = new ByteArrayOutputStream()
stream.writeTo(baos)
stream.reset()
return baos.toString(charsetName)
}
Henrique Viecili
On 14 April 2014 22:50, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Can you try using Camel 2.12.x or better with the latest 2.13 as the
> stream caching support has been improved in these releases.
>
> If its still an issue we may want to take a look at letting Camel
> reset the stream cache (if needed) when you use custom event
> notifiers.
>
> On Sun, Apr 13, 2014 at 8:57 PM, Henrique Viecili <vi...@gmail.com>
> wrote:
> > I've just faced an interesting issue with a StreamCache body being
> > 'exausted' after calling exchange.getIn().getBody(String.class) inside an
> > EventNotifier
> >
> > I'm using Camel 2.10.0 (inside JBoss Fuse 6.0) and captured an
> > ExchangeCreatedEvent on a HTTP endpoint (input). The payload was an
> > instance of InputStreamCache and after the EventNotifier executed I got a
> > 'Premature End of File' trying to parse the body as xml in the pipeline.
> >
> > Looking at the source code of InputStreamCache (extends
> > ByteArrayInputStream) the writeTo method uses IOHelper.copy which
> > 'consumes' the underlying byte array, so a next call would throw some
> > IOException. I reckon this behaviour is correct according to the
> interface
> > StreamCache.
> >
> > What I wonder is whether the automatic TypeConversion should (or not) try
> > to reset() the StreamCache after doing the type conversion, avoiding such
> > situations.
> >
> > Does this make sense? Is this fixed in the latest versions or I should
> > raise a JIRA?
> >
> > Regards,
> > Henrique Viecili
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
Re: StreamCache exausted after type conversion in EventNotifiers
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Can you try using Camel 2.12.x or better with the latest 2.13 as the
stream caching support has been improved in these releases.
If its still an issue we may want to take a look at letting Camel
reset the stream cache (if needed) when you use custom event
notifiers.
On Sun, Apr 13, 2014 at 8:57 PM, Henrique Viecili <vi...@gmail.com> wrote:
> I've just faced an interesting issue with a StreamCache body being
> 'exausted' after calling exchange.getIn().getBody(String.class) inside an
> EventNotifier
>
> I'm using Camel 2.10.0 (inside JBoss Fuse 6.0) and captured an
> ExchangeCreatedEvent on a HTTP endpoint (input). The payload was an
> instance of InputStreamCache and after the EventNotifier executed I got a
> 'Premature End of File' trying to parse the body as xml in the pipeline.
>
> Looking at the source code of InputStreamCache (extends
> ByteArrayInputStream) the writeTo method uses IOHelper.copy which
> 'consumes' the underlying byte array, so a next call would throw some
> IOException. I reckon this behaviour is correct according to the interface
> StreamCache.
>
> What I wonder is whether the automatic TypeConversion should (or not) try
> to reset() the StreamCache after doing the type conversion, avoiding such
> situations.
>
> Does this make sense? Is this fixed in the latest versions or I should
> raise a JIRA?
>
> Regards,
> Henrique Viecili
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: StreamCache exausted after type conversion in
EventNotifiers
Posted by Willem Jiang <wi...@gmail.com>.
If you consume the stream by calling the getBody(String.class), you need to call the reset method of the StreamCache.
Can you show me the camel route that you have?
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 14, 2014 at 11:57:52 AM, Henrique Viecili (viecili@gmail.com) wrote:
> I've just faced an interesting issue with a StreamCache body being
> 'exausted' after calling exchange.getIn().getBody(String.class) inside an
> EventNotifier
>
> I'm using Camel 2.10.0 (inside JBoss Fuse 6.0) and captured an
> ExchangeCreatedEvent on a HTTP endpoint (input). The payload was an
> instance of InputStreamCache and after the EventNotifier executed I got a
> 'Premature End of File' trying to parse the body as xml in the pipeline.
>
> Looking at the source code of InputStreamCache (extends
> ByteArrayInputStream) the writeTo method uses IOHelper.copy which
> 'consumes' the underlying byte array, so a next call would throw some
> IOException. I reckon this behaviour is correct according to the interface
> StreamCache.
>
> What I wonder is whether the automatic TypeConversion should (or not) try
> to reset() the StreamCache after doing the type conversion, avoiding such
> situations.
>
> Does this make sense? Is this fixed in the latest versions or I should
> raise a JIRA?
>
> Regards,
> Henrique Viecili
>