camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cappa Roberto <roberto.ca...@guest.telecomitalia.it>
Subject R: Strange behaviour of StreamCaching
Date Tue, 20 Jul 2010 12:22:21 GMT
Ok, but if the the straming was consumed in a processor that preceeds the log, how does the
content stream could be read another time from the log?

Thanks
________________________________________
Da: Claus Ibsen [claus.ibsen@gmail.com]
Inviato: martedì 20 luglio 2010 13.09
A: users@camel.apache.org
Oggetto: Re: Strange behaviour of StreamCaching

Hi

The logger will not consume streams but log that is a streaming type.
So its expected behavior.


On Tue, Jul 20, 2010 at 12:43 PM, Cappa Roberto
<roberto.cappa@guest.telecomitalia.it> wrote:
> Hi, I'm trying  to understand the use of streamcaching and I have a doubt. In a simple
case like this:
>
> from("jetty....")
> .process(.... {processor that consumes the body input stream}....)
> .to("http:....")
>
> the processor consumes the in body and it is not available for the next step (the "to"
statement). Ok.
>
> If I enable streamCaching:
>
> from("jetty....")
> .streamCaching()
> .process(.... {processor that consumes the body input stream}....)
> .to("http:....")
>
> the sample works perfectly.
>
> Now, I've found other situations that I don't undestand:
>
> from("jetty....")
> .process(.... {processor that consumes the body input stream}....)
> .to("log:logger")
> .to("http:....")
>
> If I use the logger, even if the stream caching is DISABLED, the sample works. It seems
that logger can retrieve the original (but consumed!) message and also it re-sets the original
body. How is it possibile?
>
> Also:
>
> from("jetty....")
> .streamCaching()
> .to("http:....")
> .process(.... {processor that consumes the body input stream}....)
>
> Even if the stream caching IS enabled, the sample doesn't work, because the last processor
consumes the response body. How can I enable the caching also for response?
>
> Last question: I haven't understood how exactly IN/OUT message works. In my sample, I'm
expecting to find the request in the inMessage before the ".to" call (and it is), then I'm
expecting to find the response in the outMessage after the ".to", but the response is in the
inMessage and outMessage is empty. Where I'm wrong?
>
>
> Thanks.



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Mime
View raw message