On Mon, May 17, 2010 at 3:58 PM, _Jens <[email protected]> wrote:
>
> I would like to disable the feature in the DefaultHttpBinding because of
> existing code. Our code already reads the stream content into a file, so we
> do not require this feature from the Http binding. And obviously we don't
> want to write the data twice. This is why I was asking if this is the
> intended behavior for 2.3. In that case we need to implement an HTTP binding
> that bypasses that feature.
> To be honest, I think that the Jetty component should allow me to get access
> to the pure input stream that Jetty provides. Any additional streaming into
> a file is a nice feature but should be optional. But this is up to you guys.
> I simply need to make sure that we can upgrade to 2.3 as soon as it is
> released.
>
I think the end user should *always* have the choice. And the cache
stream have bitten us before.
So I think willem should create an option which you can enable on the
endpoint to tell it to use that cached stream or not.
>
> willem.jiang 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.
>>
>> 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
>>>>
>>>>
>>>
>>
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/2.3-SNAPSHOT%3A-Stream-Caching-again-enabled-by-Bug-Fix-for-Camel-2686-and-CAMEL-2694-%28rev-941275%29--tp28582952p28583757.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
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
