Message body Disappearing

[Pete Mueller <pe...@routecloud.com>]

Hello all,

Note: I am using Camel 2.0

I have recently create a custom component that consumes text off a telnet
session, packages it into a Message class extended from DefaultMessage.  The
messages are sent down a route through 3 processors.  The problem I am
having is that after the first process completes, the body (and just the
body) of the message when it arrives at the second processor is empty.  I
have check over all of my code and I do not manipulate any part of the
exchange in the first processor, other than performing
exchange.setOut(exchange.getIn())  What makes this more interesting, is that
when the message is created the body is a Map containing many name/value
pairs, along with about 5 header fields.  When the message enters the second
processor, the header are still there, but the map has been emptied.  It has
not been NULLed, but emptied.  

I'm guessing that camel is creating a new instance of my custom message
(which has an empty Map by default) but is not transfering the body from the
old message.  I'm not sure why camel would be creating a new message in the
first place.  Does anyone have some guidance as to what may be causing this? 

I will mention another oddity with my routes as I think they may be related. 
I have since the beginning had the "trace" option on my routes during
testing.  When I began to move to production, I turned off the trace, and
saw that my processors stopped working.  I traced it down to the fact that
jetty when receiving an inbound web request creates a message of type
org.mortbay.jetty.HttpParser.Input.  When trace is on, I receive this
message with a BodyType of
org.apache.camel.converter.stream.InputStreamCache, with trace off, I
receive the Input class.  As my processors expected an InputStream, they
broke.  I am guessing that the TraceInterceptor performs a conversion on the
body before logging it. But now I am stuck, I could find a way to convert an
HttpParser.Input to something I can use, but my code has have to have
conditional checks for each class, depending whether trace is on or off.  I
also wonder if the TraceInterceptor is affecting my custom messages in a way
that is causing them to disappear.

Is this expected behavior, and if so, what is the recommended solution to
dealing with it?

Thanks for your help
-pete
-- 
View this message in context: http://old.nabble.com/Message-body-Disappearing-tp27825199p27825199.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Message body Disappearing

[Willem Jiang <wi...@gmail.com>]

Hi,

For your first question, you may take a look at the code of 
MessageSupport copy() and copyFrom().

For the second question, it's the stream caching issue, we disable the 
stream caching by default in Camel 2.x to improve the performance, and 
you can enable it as you want[1]

[1]http://camel.apache.org/stream-caching.html

Willem

Pete Mueller wrote:
> Hello all,
> 
> Note: I am using Camel 2.0
> 
> I have recently create a custom component that consumes text off a telnet
> session, packages it into a Message class extended from DefaultMessage.  The
> messages are sent down a route through 3 processors.  The problem I am
> having is that after the first process completes, the body (and just the
> body) of the message when it arrives at the second processor is empty.  I
> have check over all of my code and I do not manipulate any part of the
> exchange in the first processor, other than performing
> exchange.setOut(exchange.getIn())  What makes this more interesting, is that
> when the message is created the body is a Map containing many name/value
> pairs, along with about 5 header fields.  When the message enters the second
> processor, the header are still there, but the map has been emptied.  It has
> not been NULLed, but emptied.  
> 
> I'm guessing that camel is creating a new instance of my custom message
> (which has an empty Map by default) but is not transfering the body from the
> old message.  I'm not sure why camel would be creating a new message in the
> first place.  Does anyone have some guidance as to what may be causing this? 
> 
> I will mention another oddity with my routes as I think they may be related. 
> I have since the beginning had the "trace" option on my routes during
> testing.  When I began to move to production, I turned off the trace, and
> saw that my processors stopped working.  I traced it down to the fact that
> jetty when receiving an inbound web request creates a message of type
> org.mortbay.jetty.HttpParser.Input.  When trace is on, I receive this
> message with a BodyType of
> org.apache.camel.converter.stream.InputStreamCache, with trace off, I
> receive the Input class.  As my processors expected an InputStream, they
> broke.  I am guessing that the TraceInterceptor performs a conversion on the
> body before logging it. But now I am stuck, I could find a way to convert an
> HttpParser.Input to something I can use, but my code has have to have
> conditional checks for each class, depending whether trace is on or off.  I
> also wonder if the TraceInterceptor is affecting my custom messages in a way
> that is causing them to disappear.
> 
> Is this expected behavior, and if so, what is the recommended solution to
> dealing with it?
> 
> Thanks for your help
> -pete