OK, thanks.
/Bengt
2010/9/14 Claus Ibsen <claus.ib...@gmail.com>
> 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
>
