On Tue, Sep 14, 2010 at 9:02 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Thanks Willem and Claus,
>
> I guess we should only bother with in messages then and forget about the out
> message if we want a simple rule.
>
> I thought that the rationale for having both in- and out messages was that
> the original in message would be kept unaltered while the out message would
> gradually be transformed when passing through the pipeline. I assume now
> that you only have access to the message as it was transformed by the
> previous processor in the chain. The original message is not available - or
> is it?
>
No its not avail, unless you fetch if from the UnitOfWork. There is a
feature on the error handler to use the original message when moving a
message to the dead letter channel. Which leverages the UnitOfWork to
fetch it.
In Camel 3.0 we have plans to rework how this works internally
reducing the copying done by the pipeline and make it easier to access
the original message and/or even previous states.
> /Bengt
>
> 2010/9/14 Willem Jiang <willem.ji...@gmail.com>
>
>> On 9/11/10 10:03 PM, Christian Müller wrote:
>>
>>> Hello list!
>>>
>>> I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
>>> Camel site [1]. I also hat a short conversation with Ade from Progress
>>> about
>>> the exchange pattern, but still I have the feeling I doesn't understand
>>> all
>>> aspects. May be you can help me to understand it correct. Here are my
>>> questions:
>>> - In the book and the Camel site only the exchange patterns InOut and
>>> InOnly
>>> are mentioned but org.apache.camel.ExchangePattern defines the following
>>> exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
>>> RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
>>> - If I understood Ade correct, after each processing on a
>>> component/processor the message goes throught the pipieline before it
>>> receives the next component/processor. In the case of an InOut exchange,
>>> the
>>> pipeline will copy the out message body, headers and attachments into the
>>> in
>>> message. So that in the next component/processor can access these data
>>> from
>>> the in message again. If I use the InOnly exchange pattern, the
>>> component/processor will write the response into the in message and the
>>> pipeline has nothing to copy.
>>>
>> The pipeline always uses a new copy of exchange which will create a new
>> inMessage copy as you described, if you are using InOnly exchange pattern,
>> pipeline still create a new Exchange and copy the in message from the first
>> exchange.
>>
>> The InOnly and InOut exchange patterns always take effect in the component
>> side, current DefaultExchange will not check the exchange pattern and will
>> create a new out message which copy from the exchange in message when you
>> call the Exchange.getOutMessage().
>>
>>
>>
>> > From the end user perspective it looks like it
>>
>>> doesn't matter, whether to use the InOnly or InOut exchange pattern.
>>> - The only one component I know which handle InOnly and InOut "really"
>>> defferently is the jms-component. It will only send a reply message if the
>>> exchange pattern InOut is used.
>>> - If I use a InOnly exchange for the following routes, I takes also more
>>> than 5 seconds until my templeate.send() method returns. I would expect
>>> that
>>> the call returns after the exchange was placed into the next sub route
>>> (after a few milliseconds). My key point here is not to improve the
>>> performance. Only to understand the exchange pattern correct, how the work
>>> and how they are used in the right way...
>>>
>>> from("direct:start")
>>>
>>> .to("direct:sub");
>>>
>>>
>>>
>>> from("direct:sub")
>>>
>>> .process(*new* Processor() {
>>>
>>> �...@override
>>>
>>> *public* *void* process(Exchange exchange) *
>>> throws* Exception {
>>>
>>> Thread.*sleep*(5000);
>>>
>>> }
>>>
>>> })
>>> .to("mock:result");
>>>
>>>
>>> - Do you have recommendations when to use InOnly and InOut?
>>>
>> There are some description about InOnly and InOut message echange pattern
>> in the Camel in Action chapter 10, as the sync and async invocation. You may
>> take a look.
>>
>>
>> - If we write our own processor which modifies the in message, should they
>>> write the modified body into the out message, if the exchnage is out
>>> capable
>>> (and also copy all header and attachments we need for further processing)?
>>> Or should we always modify the in message because it requires less action?
>>>
>> You can modify the in message directly, or do some change on the out
>> message and the pipeline will pick up the right modified message for you.
>> The DefaultExchange will create a new out message based on the in message if
>> you call the Exchange.getOutMessage(), so you don't need to copy the all the
>> headers and attachments yourself.
>>
>>
>> - The same question for our own type converters. I know the type converter
>>> is implemented in this way, that it will return the new (converted)
>>> object.
>>> But our type converters also have to modify the message header. Should
>>> they
>>> also check whether the exchange is out capable and than modify the out (if
>>> out capable) or in (if not out capable) message? Is this the way camel
>>> handels the converted object from the type converter?
>>>
>>
>> I think you just need to make the change on the in message, if you want to
>> avoid the addition copying (camel will copy the out message from the in
>> message if you make the change on the out message of the exchange).
>>
>>
>>> [1] http://camel.apache.org/exchange-pattern.html
>>>
>>> Thanks in advance for your help and taking time for my questions,
>>> Christian
>>>
>>>
>> Willem
>>
>
--
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
