camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: 2.3-SNAPSHOT: Stream Caching again enabled by Bug Fix for Camel-2686 and CAMEL-2694 (rev 941275)?
Date Mon, 17 May 2010 14:43:45 GMT
On Mon, May 17, 2010 at 4:36 PM, Gert Vanthienen
<gert.vanthienen@gmail.com> wrote:
> L.S.,
>
> Instead of having this option on the endpoint, wouldn't it make more
> sense to somehow attach that as an attribute/policy to the route or on
> the routebuilder?  That way, people can enable/disable stream caching
> on that level instead of having to worry about which endpoints in
> their routes need special flags to enable/disable it.
>

There is already a steamCaching in the DSL. So you can just do
from(jetty).streamCaching().xxx

So I do think that conversion to StreamCache should be removed from
HTTPBinding. Then end users have to specify .streamCaching() in the
route to leverage it. But I suspect people may forget / dont know how
to. And thus willem made that automatic.



> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On 17 May 2010 16:19, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> On Mon, May 17, 2010 at 3:58 PM, _Jens <jens.riemschneider@icw.de> 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
>>
>



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