You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Cappa Roberto <ro...@guest.telecomitalia.it> on 2010/07/20 12:43:00 UTC
Strange behaviour of StreamCaching
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.
R: Strange behaviour of StreamCaching
Posted by Cappa Roberto <ro...@guest.telecomitalia.it>.
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
<ro...@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
Re: Strange behaviour of StreamCaching
Posted by Claus Ibsen <cl...@gmail.com>.
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
<ro...@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