Claus Ibsen wrote:
On Mon, May 17, 2010 at 3:29 PM, Willem Jiang <[email protected]> wrote:
Yes, from this point, you can't disable the Stream Caching.
But there is a difference between the Stream Caching and current Http
binding change.
If you don't enable the Stream Caching, there is no interceptor will be
used to reset the Stream for you before the message is routing to the next
endpoint.
If there are large Post message body, the Stream Caching will help you avoid
the OutOfMessage error as it can dump the message into a file.
I don't know why are your going to disable it.
Do you mean OutOfMemoryError ?
I do not think Camel should impose automatic stream cache in these situations.
The end user should always have the choice.
He could just have enabled stream caching on the route in those situations.
from(jetty).streamCaching().to(yyy);
If there is another reason why you cache the stream in HttpBinding?
There was a link in one of the JIRA tickets to this one:
http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-ts28348176.html
Which seems to been needed to fix some POST form issue?
Is this the reason?
Yes, this is the reason why I changed the code of DefaultHttpBinding.
I agree we can provide a option for the user who can get the raw
InputStream if they want, but they can't get the POST from from Message
body any more with this option.
Willem
Willem
_Jens wrote:
Hi Willem,
thanks for your quick reply. The issue is that I cannot disable
streamCaching in 2.3-SNAPSHOT anymore. This is what was changed in
DefaultHttpBinding.parseBody:
Before:
// otherwise use input stream
return HttpConverter.toInputStream(request);
Now:
// otherwise use input stream and we need to cache it first
InputStream is = HttpConverter.toInputStream(request,
httpMessage.getExchange());
if (is == null) {
return is;
}
// convert the input stream to StreamCache
try {
CachedOutputStream cos = new
CachedOutputStream(httpMessage.getExchange());
IOHelper.copy(is, cos);
return cos.getStreamCache();
} finally {
is.close();
}
This means, the CachedOutputStream is always used. I have tried to disable
this on the camelContext. But obviously the above code does not check this
option in the camelContext. So it is not possible anymore.
willem.jiang wrote:
These changes just to make sure the we can still read the post message
body even the body is form message.
You can still configure the CachedOutputStream by using the camelContext
properties, I don't know what kind of issue that the changes introduced to
you.
Willem
_Jens wrote:
Hi,
it seems to me that the DefaultHTTPBinding again uses a
CachedOutputStream.
This means that the binding cannot be used anymore with longer streams
and
that the streamCache option on the CamelContext bean is ignored. Is this
going to be the way the caching is done in 2.3?
Thanks,
Jens
