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.
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
