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: Faster!!
Date Fri, 10 Jul 2009 11:29:25 GMT
This discussion about IN, OUT, FAULT is moved to the topic we current
have on the dev forum.

This topic should be used for performance talk.


On Thu, Jul 9, 2009 at 7:44 PM, Claus Ibsen<claus.ibsen@gmail.com> wrote:
> On Thu, Jul 9, 2009 at 4:50 PM, Hadrian Zbarcea<hzbarcea@gmail.com> wrote:
>> I hardly see a reason for the IN message to be mutable.  Shouldn't it be
>> read-only to start with?
>> In my mind the IN is what you've been told, it's history, cannot be changed.
>>  If you want to echo something slightly different, you can always produce
>> the OUT you want (modified copy of the IN).
>
> That doesnt really work with the message exchange patterns. If you
> send in an InOnly and do some processing steps on the exchange, you
> can still mutate the IN message.
>
> If it was a InOut then you could advocate that IN is the original IN
> and cant mutate. And that you should alter the OUT. But then you
> cannot reuse the same processors as from InOnly.
>
>
> I cannot a this time of the hours see a good and concise model for
> this. The current behavior is the best we got at this time.
>
>
>
>
>>
>> +1 on both counts.  Properties are used in quite a few places now though,
>> mostly for components that use bindings, like Jms, File, Mail, etc.  However
>> I don't think copying properties is very expensive, plus we could optimize
>> that a bit in 2.x.
>>
>> Hadrian
>>
>> On Jul 9, 2009, at 6:35 AM, James Strachan wrote:
>>
>>> 2009/7/9 Claus Ibsen <claus.ibsen@gmail.com>:
>>>>
>>>> Hi
>>>>
>>>> See this wiki page for ideas on performance optimizations
>>>> http://camel.apache.org/camel-2x-speed-optimizations.html
>>>
>>> Copying Messages seems to be the big cost (particularly all those headers
>>> etc).
>>>
>>> I wonder if we should use in the Pipeline a ReadOnlyMessageFacade
>>> which prevents mutation of the underlying message, so the same Message
>>> can be reused (no need to make defensive copies first) and can be
>>> passed into next steps in the chain if an OUT message is not created?
>>>
>>> I'm also wondering how often we really use Exchange properties; seems
>>> we mostly use message headers; in which case creating new Exchange
>>> instances should be quite cheap - as we can just pass the IN by value
>>> each time?
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Mime
View raw message