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

Search Discussions

  • Willem Jiang at Mar 9, 2010 at 1:18 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedMar 8, '10 at 6:11p
activeMar 9, '10 at 1:18a
posts2
users2
websitecamel.apache.org

2 users in discussion

Pete Mueller: 1 post Willem Jiang: 1 post

People

Translate

site design / logo © 2021 Grokbase