You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by RuneB <ru...@spk.no> on 2009/06/18 10:23:41 UTC
Message body lost when message moved by exception clause
After upgrading from 1.5.0 to 1.6.1, we find that that exception clauses such
as this one
<onException>
<exception>my.package.SomeException</exception>
<redeliveryPolicy maximumRedeliveries="0" />
<handled>
<constant>true</constant>
</handled>
<to ref="tpforholdArbeidskoe" />
</onException>
cause the message body to be *empty* after the message has been moved to
tpforholdArbeidskoe.
(tpforholdArbeidskoe is a message queue on ActiveMQ, as is the route's
from-endpoint).
The following trace may be of relevance:
---------------------------------------------------
17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
org.apache.camel.component.jms.JmsProducer process
WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
Exchange[JmsMessage: ActiveMQTextMessage {commandId =
8, responseRequired = false, messageId =
ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination = null,
ori
ginalTransactionId = null, producerId =
ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
queue://queue.samordn
ing.TPForhold, transactionId = null, expiration = 0, timestamp =
1245251471047, arrival = 0, brokerInTime = 124525147106
3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
persistent = false, type = , priority = 0, groupID =
null, groupSequence = 0, targetConsumerId = null, compressed = false,
userID = null, content = null, marshalledProperti
es = null, dataStructure = null, redeliveryCounter = 0, size = 0, properties
= null, readOnlyProperties = true, readOnly
Body = true, droppable = false, text = <?xml version="1.0"
encoding="UTF-8"?>
<TPForholdHendelse>
<type>Opprett</type>
<ordning>1015</ordning>
<datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
<ideKundePrsnr>xxxxxx</ideKundePrsnr>
</TPForholdHendelse>
}] with destination: queue.samordning.TPForholdTilArbeidskoe
17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
org.apache.camel.processor.Logger log
SEVERE: Failed delivery for exchangeId:
ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure processor:
Trace
Interceptor[To[ref:tpforholdArbeidskoe]]
17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
org.apache.camel.processor.Logger process
INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(), Pattern:InOnly ,
Headers:{JMSTimestamp=1245251480860, org.apa
che.camel.MultiParameterArray=false, JMSType=,
org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null, JMSReplyTo=null,
JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
Redelivered=false,
JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
JMSDeliveryMode=2, JMSCorrelationID=, J
MSPriority=4} , BodyType:null , Body:null
---------------------------------------------------
Anyone know the reason why we lose the message body?
- Rune
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jun 23, 2009 at 2:12 PM, RuneB <ru...@spk.no> wrote:
>
> Ok. See CAMEL-1749.
>
Thanks I had a look into it and added my comments to the ticket.
>
> - Rune
>
>
>
>
> Claus Ibsen-2 wrote:
> >
> > On Mon, Jun 22, 2009 at 12:10 PM, RuneB <ru...@spk.no> wrote:
> >
> >>
> >> No, it's not the JAXB unmarshaller that throws the exception.
> >> Unmarshalling
> >> seems to work fine.
> >>
> >> It's for exceptions thrown *after* unmarshalling that the message body
> is
> >> lost. My testing indicates that the presence of the unmarshalling step
> >> causes message body loss if an exception occurs afterwards.
> >>
> >
> > Hi
> >
> > Could you create a JIRA ticket for this then we dont forget to look into
> > it.
> > And if possible attach a sample with the JAXB that causes this behavior.
> >
> > For instance a route in XML or Java is sufficient but a real unit test is
> > of
> > course much better.
> >
> >
> >
> >>
> >> - Rune
> >>
> >>
> >> Claus Ibsen-2 wrote:
> >> >
> >> > On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
> >> >
> >> >>
> >> >> A couple of more points:
> >> >>
> >> >> * 1.6.0 behaves like 1.6.1, as far as I can tell.
> >> >>
> >> >> * Loss of message body only occurs if *unmarshalling has taken
> place*.
> >> >> We've
> >> >> an element like this:
> >> >> <unmarshal>
> >> >> <jaxb prettyPrint="true"
> >> >> contextPath="no.spk.felles.domene.melding" />
> >> >> </unmarshal>
> >> >> If I replace this element (and the bean calls it's for), with a
> bean
> >> >> call
> >> >> that simply throws an exception,
> >> >> the message body will be intact after the message has been moved by
> >> >> onException.
> >> >>
> >> >
> >> > Is it the JAXB unmarshaller that throws the exception? Eg does the
> >> > exception
> >> > occur during JAXB unmarshalling?
> >> >
> >> > What does the body look like after the unmarshal? You can use a
> >> processor
> >> > to
> >> > do some system out, or use the Tracer in Camel to look it.
> >> >
> >> > Maybe the JAXB clears the body before hand it tries to convert it.
> >> >
> >> >
> >> > As a side note:
> >> > In Camel 2.0 there is a new option: useOriginalBody that allows you to
> >> use
> >> > the body that you received when the route started.
> >> > This allows you to store the original payload instead of the mutated.
> >> >
> >> >
> >> >
> >> >
> >> >> - Rune
> >> >>
> >> >>
> >> >>
> >> >> Claus Ibsen-2 wrote:
> >> >> >
> >> >> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
> >> >> >
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> The message body is definitely there when the message is consumed
> >> from
> >> >> >> the
> >> >> >> original queue.
> >> >> >>
> >> >> >> It's in the moving to the destination queue, as a result of an
> >> >> exception,
> >> >> >> that the message body is lost.
> >> >> >>
> >> >> >> I'm inspecting the destination queue using the ActiveMQ admin
> tool.
> >> >> Also,
> >> >> >> we
> >> >> >> have a bean that in turn consumes the destination queue; debugging
> >> >> this
> >> >> >> bean
> >> >> >> confirms that the body is lost.
> >> >> >>
> >> >> >> I'll get back to you about the other things you asked.
> >> >> >
> >> >> >
> >> >> > Cool. I will be out of office in a hour or so, but will be back on
> >> >> monday.
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> - Rune
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Claus Ibsen-2 wrote:
> >> >> >> >
> >> >> >> > Hi
> >> >> >> > No we have not have this reported before.
> >> >> >> > Could you create a small unit test that demonstrates this bug /
> >> >> issue?
> >> >> >> >
> >> >> >> > Do you say you loose the body when you consume it from the JMS
> >> >> queue?
> >> >> >> > Or do you lose the body before its sent to the JMS queue?
> >> >> >> > eg when you use a JMS queue browser can you see the body?
> >> >> >> >
> >> >> >> > Can you try with 1.6.0 also. That would help narrow down the
> >> number
> >> >> of
> >> >> >> > code
> >> >> >> > changes in between.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no>
> wrote:
> >> >> >> >
> >> >> >> >>
> >> >> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that
> exception
> >> >> >> clauses
> >> >> >> >> such
> >> >> >> >> as this one
> >> >> >> >>
> >> >> >> >> <onException>
> >> >> >> >> <exception>my.package.SomeException</exception>
> >> >> >> >> <redeliveryPolicy maximumRedeliveries="0" />
> >> >> >> >> <handled>
> >> >> >> >> <constant>true</constant>
> >> >> >> >> </handled>
> >> >> >> >> <to ref="tpforholdArbeidskoe" />
> >> >> >> >> </onException>
> >> >> >> >>
> >> >> >> >> cause the message body to be *empty* after the message has been
> >> >> moved
> >> >> >> to
> >> >> >> >> tpforholdArbeidskoe.
> >> >> >> >>
> >> >> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
> >> >> route's
> >> >> >> >> from-endpoint).
> >> >> >> >>
> >> >> >> >> The following trace may be of relevance:
> >> >> >> >> ---------------------------------------------------
> >> >> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> >> org.apache.camel.component.jms.JmsProducer process
> >> >> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT
> >> capable:
> >> >> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
> >> >> >> >> 8, responseRequired = false, messageId =
> >> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4,
> >> originalDestination
> >> >> =
> >> >> >> >> null,
> >> >> >> >> ori
> >> >> >> >> ginalTransactionId = null, producerId =
> >> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
> >> >> >> >> queue://queue.samordn
> >> >> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp
> =
> >> >> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
> >> >> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo =
> >> null,
> >> >> >> >> persistent = false, type = , priority = 0, groupID =
> >> >> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
> >> >> false,
> >> >> >> >> userID = null, content = null, marshalledProperti
> >> >> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size =
> >> 0,
> >> >> >> >> properties
> >> >> >> >> = null, readOnlyProperties = true, readOnly
> >> >> >> >> Body = true, droppable = false, text = <?xml version="1.0"
> >> >> >> >> encoding="UTF-8"?>
> >> >> >> >> <TPForholdHendelse>
> >> >> >> >> <type>Opprett</type>
> >> >> >> >> <ordning>1015</ordning>
> >> >> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
> >> >> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
> >> >> >> >> </TPForholdHendelse>
> >> >> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
> >> >> >> >>
> >> >> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> >> org.apache.camel.processor.Logger log
> >> >> >> >> SEVERE: Failed delivery for exchangeId:
> >> >> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
> >> >> >> >> processor:
> >> >> >> >> Trace
> >> >> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
> >> >> >> >>
> >> >> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> >> org.apache.camel.processor.Logger process
> >> >> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
> >> >> >> Pattern:InOnly
> >> >> >> >> ,
> >> >> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
> >> >> >> >> che.camel.MultiParameterArray=false, JMSType=,
> >> >> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
> >> >> >> JMSReplyTo=null,
> >> >> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
> >> >> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
> >> >> >> >> Redelivered=false,
> >> >> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
> >> >> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
> >> >> >> >> MSPriority=4} , BodyType:null , Body:null
> >> >> >> >> ---------------------------------------------------
> >> >> >> >>
> >> >> >> >> Anyone know the reason why we lose the message body?
> >> >> >> >>
> >> >> >> >> - Rune
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
> >> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Claus Ibsen
> >> >> >> > Apache Camel Committer
> >> >> >> >
> >> >> >> > Open Source Integration: http://fusesource.com
> >> >> >> > Blog: http://davsclaus.blogspot.com/
> >> >> >> > Twitter: http://twitter.com/davsclaus
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Claus Ibsen
> >> >> > Apache Camel Committer
> >> >> >
> >> >> > Open Source Integration: http://fusesource.com
> >> >> > Blog: http://davsclaus.blogspot.com/
> >> >> > Twitter: http://twitter.com/davsclaus
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Claus Ibsen
> >> > Apache Camel Committer
> >> >
> >> > Open Source Integration: http://fusesource.com
> >> > Blog: http://davsclaus.blogspot.com/
> >> > Twitter: http://twitter.com/davsclaus
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24144738.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Claus Ibsen
> > Apache Camel Committer
> >
> > Open Source Integration: http://fusesource.com
> > Blog: http://davsclaus.blogspot.com/
> > Twitter: http://twitter.com/davsclaus
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24164806.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Message body lost when message moved by exception clause
Posted by RuneB <ru...@spk.no>.
Ok. See CAMEL-1749.
- Rune
Claus Ibsen-2 wrote:
>
> On Mon, Jun 22, 2009 at 12:10 PM, RuneB <ru...@spk.no> wrote:
>
>>
>> No, it's not the JAXB unmarshaller that throws the exception.
>> Unmarshalling
>> seems to work fine.
>>
>> It's for exceptions thrown *after* unmarshalling that the message body is
>> lost. My testing indicates that the presence of the unmarshalling step
>> causes message body loss if an exception occurs afterwards.
>>
>
> Hi
>
> Could you create a JIRA ticket for this then we dont forget to look into
> it.
> And if possible attach a sample with the JAXB that causes this behavior.
>
> For instance a route in XML or Java is sufficient but a real unit test is
> of
> course much better.
>
>
>
>>
>> - Rune
>>
>>
>> Claus Ibsen-2 wrote:
>> >
>> > On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
>> >
>> >>
>> >> A couple of more points:
>> >>
>> >> * 1.6.0 behaves like 1.6.1, as far as I can tell.
>> >>
>> >> * Loss of message body only occurs if *unmarshalling has taken place*.
>> >> We've
>> >> an element like this:
>> >> <unmarshal>
>> >> <jaxb prettyPrint="true"
>> >> contextPath="no.spk.felles.domene.melding" />
>> >> </unmarshal>
>> >> If I replace this element (and the bean calls it's for), with a bean
>> >> call
>> >> that simply throws an exception,
>> >> the message body will be intact after the message has been moved by
>> >> onException.
>> >>
>> >
>> > Is it the JAXB unmarshaller that throws the exception? Eg does the
>> > exception
>> > occur during JAXB unmarshalling?
>> >
>> > What does the body look like after the unmarshal? You can use a
>> processor
>> > to
>> > do some system out, or use the Tracer in Camel to look it.
>> >
>> > Maybe the JAXB clears the body before hand it tries to convert it.
>> >
>> >
>> > As a side note:
>> > In Camel 2.0 there is a new option: useOriginalBody that allows you to
>> use
>> > the body that you received when the route started.
>> > This allows you to store the original payload instead of the mutated.
>> >
>> >
>> >
>> >
>> >> - Rune
>> >>
>> >>
>> >>
>> >> Claus Ibsen-2 wrote:
>> >> >
>> >> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
>> >> >
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> The message body is definitely there when the message is consumed
>> from
>> >> >> the
>> >> >> original queue.
>> >> >>
>> >> >> It's in the moving to the destination queue, as a result of an
>> >> exception,
>> >> >> that the message body is lost.
>> >> >>
>> >> >> I'm inspecting the destination queue using the ActiveMQ admin tool.
>> >> Also,
>> >> >> we
>> >> >> have a bean that in turn consumes the destination queue; debugging
>> >> this
>> >> >> bean
>> >> >> confirms that the body is lost.
>> >> >>
>> >> >> I'll get back to you about the other things you asked.
>> >> >
>> >> >
>> >> > Cool. I will be out of office in a hour or so, but will be back on
>> >> monday.
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> - Rune
>> >> >>
>> >> >>
>> >> >>
>> >> >> Claus Ibsen-2 wrote:
>> >> >> >
>> >> >> > Hi
>> >> >> > No we have not have this reported before.
>> >> >> > Could you create a small unit test that demonstrates this bug /
>> >> issue?
>> >> >> >
>> >> >> > Do you say you loose the body when you consume it from the JMS
>> >> queue?
>> >> >> > Or do you lose the body before its sent to the JMS queue?
>> >> >> > eg when you use a JMS queue browser can you see the body?
>> >> >> >
>> >> >> > Can you try with 1.6.0 also. That would help narrow down the
>> number
>> >> of
>> >> >> > code
>> >> >> > changes in between.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
>> >> >> clauses
>> >> >> >> such
>> >> >> >> as this one
>> >> >> >>
>> >> >> >> <onException>
>> >> >> >> <exception>my.package.SomeException</exception>
>> >> >> >> <redeliveryPolicy maximumRedeliveries="0" />
>> >> >> >> <handled>
>> >> >> >> <constant>true</constant>
>> >> >> >> </handled>
>> >> >> >> <to ref="tpforholdArbeidskoe" />
>> >> >> >> </onException>
>> >> >> >>
>> >> >> >> cause the message body to be *empty* after the message has been
>> >> moved
>> >> >> to
>> >> >> >> tpforholdArbeidskoe.
>> >> >> >>
>> >> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
>> >> route's
>> >> >> >> from-endpoint).
>> >> >> >>
>> >> >> >> The following trace may be of relevance:
>> >> >> >> ---------------------------------------------------
>> >> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.component.jms.JmsProducer process
>> >> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT
>> capable:
>> >> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
>> >> >> >> 8, responseRequired = false, messageId =
>> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4,
>> originalDestination
>> >> =
>> >> >> >> null,
>> >> >> >> ori
>> >> >> >> ginalTransactionId = null, producerId =
>> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
>> >> >> >> queue://queue.samordn
>> >> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
>> >> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
>> >> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo =
>> null,
>> >> >> >> persistent = false, type = , priority = 0, groupID =
>> >> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
>> >> false,
>> >> >> >> userID = null, content = null, marshalledProperti
>> >> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size =
>> 0,
>> >> >> >> properties
>> >> >> >> = null, readOnlyProperties = true, readOnly
>> >> >> >> Body = true, droppable = false, text = <?xml version="1.0"
>> >> >> >> encoding="UTF-8"?>
>> >> >> >> <TPForholdHendelse>
>> >> >> >> <type>Opprett</type>
>> >> >> >> <ordning>1015</ordning>
>> >> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
>> >> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
>> >> >> >> </TPForholdHendelse>
>> >> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>> >> >> >>
>> >> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.processor.Logger log
>> >> >> >> SEVERE: Failed delivery for exchangeId:
>> >> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
>> >> >> >> processor:
>> >> >> >> Trace
>> >> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
>> >> >> >>
>> >> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.processor.Logger process
>> >> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
>> >> >> Pattern:InOnly
>> >> >> >> ,
>> >> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
>> >> >> >> che.camel.MultiParameterArray=false, JMSType=,
>> >> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
>> >> >> JMSReplyTo=null,
>> >> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
>> >> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
>> >> >> >> Redelivered=false,
>> >> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
>> >> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
>> >> >> >> MSPriority=4} , BodyType:null , Body:null
>> >> >> >> ---------------------------------------------------
>> >> >> >>
>> >> >> >> Anyone know the reason why we lose the message body?
>> >> >> >>
>> >> >> >> - Rune
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
>> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Claus Ibsen
>> >> >> > Apache Camel Committer
>> >> >> >
>> >> >> > Open Source Integration: http://fusesource.com
>> >> >> > Blog: http://davsclaus.blogspot.com/
>> >> >> > Twitter: http://twitter.com/davsclaus
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Claus Ibsen
>> >> > Apache Camel Committer
>> >> >
>> >> > Open Source Integration: http://fusesource.com
>> >> > Blog: http://davsclaus.blogspot.com/
>> >> > Twitter: http://twitter.com/davsclaus
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Claus Ibsen
>> > Apache Camel Committer
>> >
>> > Open Source Integration: http://fusesource.com
>> > Blog: http://davsclaus.blogspot.com/
>> > Twitter: http://twitter.com/davsclaus
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24144738.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24164806.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by RuneB <ru...@spk.no>.
Claus Ibsen-2 wrote:
>
> On Mon, Jun 22, 2009 at 12:10 PM, RuneB <ru...@spk.no> wrote:
>
>>
>> No, it's not the JAXB unmarshaller that throws the exception.
>> Unmarshalling
>> seems to work fine.
>>
>> It's for exceptions thrown *after* unmarshalling that the message body is
>> lost. My testing indicates that the presence of the unmarshalling step
>> causes message body loss if an exception occurs afterwards.
>>
>
> Hi
>
> Could you create a JIRA ticket for this then we dont forget to look into
> it.
> And if possible attach a sample with the JAXB that causes this behavior.
>
> For instance a route in XML or Java is sufficient but a real unit test is
> of
> course much better.
>
> Done. See CAMEL-1749 for a complete app the demonstrates the issue.
>
> - Rune
>
>>
>> - Rune
>>
>>
>> Claus Ibsen-2 wrote:
>> >
>> > On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
>> >
>> >>
>> >> A couple of more points:
>> >>
>> >> * 1.6.0 behaves like 1.6.1, as far as I can tell.
>> >>
>> >> * Loss of message body only occurs if *unmarshalling has taken place*.
>> >> We've
>> >> an element like this:
>> >> <unmarshal>
>> >> <jaxb prettyPrint="true"
>> >> contextPath="no.spk.felles.domene.melding" />
>> >> </unmarshal>
>> >> If I replace this element (and the bean calls it's for), with a bean
>> >> call
>> >> that simply throws an exception,
>> >> the message body will be intact after the message has been moved by
>> >> onException.
>> >>
>> >
>> > Is it the JAXB unmarshaller that throws the exception? Eg does the
>> > exception
>> > occur during JAXB unmarshalling?
>> >
>> > What does the body look like after the unmarshal? You can use a
>> processor
>> > to
>> > do some system out, or use the Tracer in Camel to look it.
>> >
>> > Maybe the JAXB clears the body before hand it tries to convert it.
>> >
>> >
>> > As a side note:
>> > In Camel 2.0 there is a new option: useOriginalBody that allows you to
>> use
>> > the body that you received when the route started.
>> > This allows you to store the original payload instead of the mutated.
>> >
>> >
>> >
>> >
>> >> - Rune
>> >>
>> >>
>> >>
>> >> Claus Ibsen-2 wrote:
>> >> >
>> >> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
>> >> >
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> The message body is definitely there when the message is consumed
>> from
>> >> >> the
>> >> >> original queue.
>> >> >>
>> >> >> It's in the moving to the destination queue, as a result of an
>> >> exception,
>> >> >> that the message body is lost.
>> >> >>
>> >> >> I'm inspecting the destination queue using the ActiveMQ admin tool.
>> >> Also,
>> >> >> we
>> >> >> have a bean that in turn consumes the destination queue; debugging
>> >> this
>> >> >> bean
>> >> >> confirms that the body is lost.
>> >> >>
>> >> >> I'll get back to you about the other things you asked.
>> >> >
>> >> >
>> >> > Cool. I will be out of office in a hour or so, but will be back on
>> >> monday.
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> - Rune
>> >> >>
>> >> >>
>> >> >>
>> >> >> Claus Ibsen-2 wrote:
>> >> >> >
>> >> >> > Hi
>> >> >> > No we have not have this reported before.
>> >> >> > Could you create a small unit test that demonstrates this bug /
>> >> issue?
>> >> >> >
>> >> >> > Do you say you loose the body when you consume it from the JMS
>> >> queue?
>> >> >> > Or do you lose the body before its sent to the JMS queue?
>> >> >> > eg when you use a JMS queue browser can you see the body?
>> >> >> >
>> >> >> > Can you try with 1.6.0 also. That would help narrow down the
>> number
>> >> of
>> >> >> > code
>> >> >> > changes in between.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
>> >> >> clauses
>> >> >> >> such
>> >> >> >> as this one
>> >> >> >>
>> >> >> >> <onException>
>> >> >> >> <exception>my.package.SomeException</exception>
>> >> >> >> <redeliveryPolicy maximumRedeliveries="0" />
>> >> >> >> <handled>
>> >> >> >> <constant>true</constant>
>> >> >> >> </handled>
>> >> >> >> <to ref="tpforholdArbeidskoe" />
>> >> >> >> </onException>
>> >> >> >>
>> >> >> >> cause the message body to be *empty* after the message has been
>> >> moved
>> >> >> to
>> >> >> >> tpforholdArbeidskoe.
>> >> >> >>
>> >> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
>> >> route's
>> >> >> >> from-endpoint).
>> >> >> >>
>> >> >> >> The following trace may be of relevance:
>> >> >> >> ---------------------------------------------------
>> >> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.component.jms.JmsProducer process
>> >> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT
>> capable:
>> >> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
>> >> >> >> 8, responseRequired = false, messageId =
>> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4,
>> originalDestination
>> >> =
>> >> >> >> null,
>> >> >> >> ori
>> >> >> >> ginalTransactionId = null, producerId =
>> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
>> >> >> >> queue://queue.samordn
>> >> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
>> >> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
>> >> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo =
>> null,
>> >> >> >> persistent = false, type = , priority = 0, groupID =
>> >> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
>> >> false,
>> >> >> >> userID = null, content = null, marshalledProperti
>> >> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size =
>> 0,
>> >> >> >> properties
>> >> >> >> = null, readOnlyProperties = true, readOnly
>> >> >> >> Body = true, droppable = false, text = <?xml version="1.0"
>> >> >> >> encoding="UTF-8"?>
>> >> >> >> <TPForholdHendelse>
>> >> >> >> <type>Opprett</type>
>> >> >> >> <ordning>1015</ordning>
>> >> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
>> >> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
>> >> >> >> </TPForholdHendelse>
>> >> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>> >> >> >>
>> >> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.processor.Logger log
>> >> >> >> SEVERE: Failed delivery for exchangeId:
>> >> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
>> >> >> >> processor:
>> >> >> >> Trace
>> >> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
>> >> >> >>
>> >> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> >> org.apache.camel.processor.Logger process
>> >> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
>> >> >> Pattern:InOnly
>> >> >> >> ,
>> >> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
>> >> >> >> che.camel.MultiParameterArray=false, JMSType=,
>> >> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
>> >> >> JMSReplyTo=null,
>> >> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
>> >> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
>> >> >> >> Redelivered=false,
>> >> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
>> >> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
>> >> >> >> MSPriority=4} , BodyType:null , Body:null
>> >> >> >> ---------------------------------------------------
>> >> >> >>
>> >> >> >> Anyone know the reason why we lose the message body?
>> >> >> >>
>> >> >> >> - Rune
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
>> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Claus Ibsen
>> >> >> > Apache Camel Committer
>> >> >> >
>> >> >> > Open Source Integration: http://fusesource.com
>> >> >> > Blog: http://davsclaus.blogspot.com/
>> >> >> > Twitter: http://twitter.com/davsclaus
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Claus Ibsen
>> >> > Apache Camel Committer
>> >> >
>> >> > Open Source Integration: http://fusesource.com
>> >> > Blog: http://davsclaus.blogspot.com/
>> >> > Twitter: http://twitter.com/davsclaus
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Claus Ibsen
>> > Apache Camel Committer
>> >
>> > Open Source Integration: http://fusesource.com
>> > Blog: http://davsclaus.blogspot.com/
>> > Twitter: http://twitter.com/davsclaus
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24144738.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24164770.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jun 22, 2009 at 12:10 PM, RuneB <ru...@spk.no> wrote:
>
> No, it's not the JAXB unmarshaller that throws the exception. Unmarshalling
> seems to work fine.
>
> It's for exceptions thrown *after* unmarshalling that the message body is
> lost. My testing indicates that the presence of the unmarshalling step
> causes message body loss if an exception occurs afterwards.
>
Hi
Could you create a JIRA ticket for this then we dont forget to look into it.
And if possible attach a sample with the JAXB that causes this behavior.
For instance a route in XML or Java is sufficient but a real unit test is of
course much better.
>
> - Rune
>
>
> Claus Ibsen-2 wrote:
> >
> > On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
> >
> >>
> >> A couple of more points:
> >>
> >> * 1.6.0 behaves like 1.6.1, as far as I can tell.
> >>
> >> * Loss of message body only occurs if *unmarshalling has taken place*.
> >> We've
> >> an element like this:
> >> <unmarshal>
> >> <jaxb prettyPrint="true"
> >> contextPath="no.spk.felles.domene.melding" />
> >> </unmarshal>
> >> If I replace this element (and the bean calls it's for), with a bean
> >> call
> >> that simply throws an exception,
> >> the message body will be intact after the message has been moved by
> >> onException.
> >>
> >
> > Is it the JAXB unmarshaller that throws the exception? Eg does the
> > exception
> > occur during JAXB unmarshalling?
> >
> > What does the body look like after the unmarshal? You can use a processor
> > to
> > do some system out, or use the Tracer in Camel to look it.
> >
> > Maybe the JAXB clears the body before hand it tries to convert it.
> >
> >
> > As a side note:
> > In Camel 2.0 there is a new option: useOriginalBody that allows you to
> use
> > the body that you received when the route started.
> > This allows you to store the original payload instead of the mutated.
> >
> >
> >
> >
> >> - Rune
> >>
> >>
> >>
> >> Claus Ibsen-2 wrote:
> >> >
> >> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
> >> >
> >> >>
> >> >> Hi,
> >> >>
> >> >> The message body is definitely there when the message is consumed
> from
> >> >> the
> >> >> original queue.
> >> >>
> >> >> It's in the moving to the destination queue, as a result of an
> >> exception,
> >> >> that the message body is lost.
> >> >>
> >> >> I'm inspecting the destination queue using the ActiveMQ admin tool.
> >> Also,
> >> >> we
> >> >> have a bean that in turn consumes the destination queue; debugging
> >> this
> >> >> bean
> >> >> confirms that the body is lost.
> >> >>
> >> >> I'll get back to you about the other things you asked.
> >> >
> >> >
> >> > Cool. I will be out of office in a hour or so, but will be back on
> >> monday.
> >> >
> >> >
> >> >
> >> >>
> >> >>
> >> >> - Rune
> >> >>
> >> >>
> >> >>
> >> >> Claus Ibsen-2 wrote:
> >> >> >
> >> >> > Hi
> >> >> > No we have not have this reported before.
> >> >> > Could you create a small unit test that demonstrates this bug /
> >> issue?
> >> >> >
> >> >> > Do you say you loose the body when you consume it from the JMS
> >> queue?
> >> >> > Or do you lose the body before its sent to the JMS queue?
> >> >> > eg when you use a JMS queue browser can you see the body?
> >> >> >
> >> >> > Can you try with 1.6.0 also. That would help narrow down the number
> >> of
> >> >> > code
> >> >> > changes in between.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
> >> >> >
> >> >> >>
> >> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
> >> >> clauses
> >> >> >> such
> >> >> >> as this one
> >> >> >>
> >> >> >> <onException>
> >> >> >> <exception>my.package.SomeException</exception>
> >> >> >> <redeliveryPolicy maximumRedeliveries="0" />
> >> >> >> <handled>
> >> >> >> <constant>true</constant>
> >> >> >> </handled>
> >> >> >> <to ref="tpforholdArbeidskoe" />
> >> >> >> </onException>
> >> >> >>
> >> >> >> cause the message body to be *empty* after the message has been
> >> moved
> >> >> to
> >> >> >> tpforholdArbeidskoe.
> >> >> >>
> >> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
> >> route's
> >> >> >> from-endpoint).
> >> >> >>
> >> >> >> The following trace may be of relevance:
> >> >> >> ---------------------------------------------------
> >> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> org.apache.camel.component.jms.JmsProducer process
> >> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
> >> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
> >> >> >> 8, responseRequired = false, messageId =
> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination
> >> =
> >> >> >> null,
> >> >> >> ori
> >> >> >> ginalTransactionId = null, producerId =
> >> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
> >> >> >> queue://queue.samordn
> >> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
> >> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
> >> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo =
> null,
> >> >> >> persistent = false, type = , priority = 0, groupID =
> >> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
> >> false,
> >> >> >> userID = null, content = null, marshalledProperti
> >> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
> >> >> >> properties
> >> >> >> = null, readOnlyProperties = true, readOnly
> >> >> >> Body = true, droppable = false, text = <?xml version="1.0"
> >> >> >> encoding="UTF-8"?>
> >> >> >> <TPForholdHendelse>
> >> >> >> <type>Opprett</type>
> >> >> >> <ordning>1015</ordning>
> >> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
> >> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
> >> >> >> </TPForholdHendelse>
> >> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
> >> >> >>
> >> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> org.apache.camel.processor.Logger log
> >> >> >> SEVERE: Failed delivery for exchangeId:
> >> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
> >> >> >> processor:
> >> >> >> Trace
> >> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
> >> >> >>
> >> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> >> org.apache.camel.processor.Logger process
> >> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
> >> >> Pattern:InOnly
> >> >> >> ,
> >> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
> >> >> >> che.camel.MultiParameterArray=false, JMSType=,
> >> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
> >> >> JMSReplyTo=null,
> >> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
> >> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
> >> >> >> Redelivered=false,
> >> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
> >> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
> >> >> >> MSPriority=4} , BodyType:null , Body:null
> >> >> >> ---------------------------------------------------
> >> >> >>
> >> >> >> Anyone know the reason why we lose the message body?
> >> >> >>
> >> >> >> - Rune
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Claus Ibsen
> >> >> > Apache Camel Committer
> >> >> >
> >> >> > Open Source Integration: http://fusesource.com
> >> >> > Blog: http://davsclaus.blogspot.com/
> >> >> > Twitter: http://twitter.com/davsclaus
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Claus Ibsen
> >> > Apache Camel Committer
> >> >
> >> > Open Source Integration: http://fusesource.com
> >> > Blog: http://davsclaus.blogspot.com/
> >> > Twitter: http://twitter.com/davsclaus
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Claus Ibsen
> > Apache Camel Committer
> >
> > Open Source Integration: http://fusesource.com
> > Blog: http://davsclaus.blogspot.com/
> > Twitter: http://twitter.com/davsclaus
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24144738.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Message body lost when message moved by exception clause
Posted by RuneB <ru...@spk.no>.
No, it's not the JAXB unmarshaller that throws the exception. Unmarshalling
seems to work fine.
It's for exceptions thrown *after* unmarshalling that the message body is
lost. My testing indicates that the presence of the unmarshalling step
causes message body loss if an exception occurs afterwards.
- Rune
Claus Ibsen-2 wrote:
>
> On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
>
>>
>> A couple of more points:
>>
>> * 1.6.0 behaves like 1.6.1, as far as I can tell.
>>
>> * Loss of message body only occurs if *unmarshalling has taken place*.
>> We've
>> an element like this:
>> <unmarshal>
>> <jaxb prettyPrint="true"
>> contextPath="no.spk.felles.domene.melding" />
>> </unmarshal>
>> If I replace this element (and the bean calls it's for), with a bean
>> call
>> that simply throws an exception,
>> the message body will be intact after the message has been moved by
>> onException.
>>
>
> Is it the JAXB unmarshaller that throws the exception? Eg does the
> exception
> occur during JAXB unmarshalling?
>
> What does the body look like after the unmarshal? You can use a processor
> to
> do some system out, or use the Tracer in Camel to look it.
>
> Maybe the JAXB clears the body before hand it tries to convert it.
>
>
> As a side note:
> In Camel 2.0 there is a new option: useOriginalBody that allows you to use
> the body that you received when the route started.
> This allows you to store the original payload instead of the mutated.
>
>
>
>
>> - Rune
>>
>>
>>
>> Claus Ibsen-2 wrote:
>> >
>> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> The message body is definitely there when the message is consumed from
>> >> the
>> >> original queue.
>> >>
>> >> It's in the moving to the destination queue, as a result of an
>> exception,
>> >> that the message body is lost.
>> >>
>> >> I'm inspecting the destination queue using the ActiveMQ admin tool.
>> Also,
>> >> we
>> >> have a bean that in turn consumes the destination queue; debugging
>> this
>> >> bean
>> >> confirms that the body is lost.
>> >>
>> >> I'll get back to you about the other things you asked.
>> >
>> >
>> > Cool. I will be out of office in a hour or so, but will be back on
>> monday.
>> >
>> >
>> >
>> >>
>> >>
>> >> - Rune
>> >>
>> >>
>> >>
>> >> Claus Ibsen-2 wrote:
>> >> >
>> >> > Hi
>> >> > No we have not have this reported before.
>> >> > Could you create a small unit test that demonstrates this bug /
>> issue?
>> >> >
>> >> > Do you say you loose the body when you consume it from the JMS
>> queue?
>> >> > Or do you lose the body before its sent to the JMS queue?
>> >> > eg when you use a JMS queue browser can you see the body?
>> >> >
>> >> > Can you try with 1.6.0 also. That would help narrow down the number
>> of
>> >> > code
>> >> > changes in between.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>> >> >
>> >> >>
>> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
>> >> clauses
>> >> >> such
>> >> >> as this one
>> >> >>
>> >> >> <onException>
>> >> >> <exception>my.package.SomeException</exception>
>> >> >> <redeliveryPolicy maximumRedeliveries="0" />
>> >> >> <handled>
>> >> >> <constant>true</constant>
>> >> >> </handled>
>> >> >> <to ref="tpforholdArbeidskoe" />
>> >> >> </onException>
>> >> >>
>> >> >> cause the message body to be *empty* after the message has been
>> moved
>> >> to
>> >> >> tpforholdArbeidskoe.
>> >> >>
>> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
>> route's
>> >> >> from-endpoint).
>> >> >>
>> >> >> The following trace may be of relevance:
>> >> >> ---------------------------------------------------
>> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> org.apache.camel.component.jms.JmsProducer process
>> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
>> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
>> >> >> 8, responseRequired = false, messageId =
>> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination
>> =
>> >> >> null,
>> >> >> ori
>> >> >> ginalTransactionId = null, producerId =
>> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
>> >> >> queue://queue.samordn
>> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
>> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
>> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
>> >> >> persistent = false, type = , priority = 0, groupID =
>> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
>> false,
>> >> >> userID = null, content = null, marshalledProperti
>> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
>> >> >> properties
>> >> >> = null, readOnlyProperties = true, readOnly
>> >> >> Body = true, droppable = false, text = <?xml version="1.0"
>> >> >> encoding="UTF-8"?>
>> >> >> <TPForholdHendelse>
>> >> >> <type>Opprett</type>
>> >> >> <ordning>1015</ordning>
>> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
>> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
>> >> >> </TPForholdHendelse>
>> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>> >> >>
>> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> org.apache.camel.processor.Logger log
>> >> >> SEVERE: Failed delivery for exchangeId:
>> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
>> >> >> processor:
>> >> >> Trace
>> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
>> >> >>
>> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> >> org.apache.camel.processor.Logger process
>> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
>> >> Pattern:InOnly
>> >> >> ,
>> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
>> >> >> che.camel.MultiParameterArray=false, JMSType=,
>> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
>> >> JMSReplyTo=null,
>> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
>> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
>> >> >> Redelivered=false,
>> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
>> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
>> >> >> MSPriority=4} , BodyType:null , Body:null
>> >> >> ---------------------------------------------------
>> >> >>
>> >> >> Anyone know the reason why we lose the message body?
>> >> >>
>> >> >> - Rune
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Claus Ibsen
>> >> > Apache Camel Committer
>> >> >
>> >> > Open Source Integration: http://fusesource.com
>> >> > Blog: http://davsclaus.blogspot.com/
>> >> > Twitter: http://twitter.com/davsclaus
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Claus Ibsen
>> > Apache Camel Committer
>> >
>> > Open Source Integration: http://fusesource.com
>> > Blog: http://davsclaus.blogspot.com/
>> > Twitter: http://twitter.com/davsclaus
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24144738.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Jun 18, 2009 at 3:28 PM, RuneB <ru...@spk.no> wrote:
>
> A couple of more points:
>
> * 1.6.0 behaves like 1.6.1, as far as I can tell.
>
> * Loss of message body only occurs if *unmarshalling has taken place*.
> We've
> an element like this:
> <unmarshal>
> <jaxb prettyPrint="true"
> contextPath="no.spk.felles.domene.melding" />
> </unmarshal>
> If I replace this element (and the bean calls it's for), with a bean call
> that simply throws an exception,
> the message body will be intact after the message has been moved by
> onException.
>
Is it the JAXB unmarshaller that throws the exception? Eg does the exception
occur during JAXB unmarshalling?
What does the body look like after the unmarshal? You can use a processor to
do some system out, or use the Tracer in Camel to look it.
Maybe the JAXB clears the body before hand it tries to convert it.
As a side note:
In Camel 2.0 there is a new option: useOriginalBody that allows you to use
the body that you received when the route started.
This allows you to store the original payload instead of the mutated.
> - Rune
>
>
>
> Claus Ibsen-2 wrote:
> >
> > On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
> >
> >>
> >> Hi,
> >>
> >> The message body is definitely there when the message is consumed from
> >> the
> >> original queue.
> >>
> >> It's in the moving to the destination queue, as a result of an
> exception,
> >> that the message body is lost.
> >>
> >> I'm inspecting the destination queue using the ActiveMQ admin tool.
> Also,
> >> we
> >> have a bean that in turn consumes the destination queue; debugging this
> >> bean
> >> confirms that the body is lost.
> >>
> >> I'll get back to you about the other things you asked.
> >
> >
> > Cool. I will be out of office in a hour or so, but will be back on
> monday.
> >
> >
> >
> >>
> >>
> >> - Rune
> >>
> >>
> >>
> >> Claus Ibsen-2 wrote:
> >> >
> >> > Hi
> >> > No we have not have this reported before.
> >> > Could you create a small unit test that demonstrates this bug / issue?
> >> >
> >> > Do you say you loose the body when you consume it from the JMS queue?
> >> > Or do you lose the body before its sent to the JMS queue?
> >> > eg when you use a JMS queue browser can you see the body?
> >> >
> >> > Can you try with 1.6.0 also. That would help narrow down the number of
> >> > code
> >> > changes in between.
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
> >> >
> >> >>
> >> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
> >> clauses
> >> >> such
> >> >> as this one
> >> >>
> >> >> <onException>
> >> >> <exception>my.package.SomeException</exception>
> >> >> <redeliveryPolicy maximumRedeliveries="0" />
> >> >> <handled>
> >> >> <constant>true</constant>
> >> >> </handled>
> >> >> <to ref="tpforholdArbeidskoe" />
> >> >> </onException>
> >> >>
> >> >> cause the message body to be *empty* after the message has been moved
> >> to
> >> >> tpforholdArbeidskoe.
> >> >>
> >> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the
> route's
> >> >> from-endpoint).
> >> >>
> >> >> The following trace may be of relevance:
> >> >> ---------------------------------------------------
> >> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> org.apache.camel.component.jms.JmsProducer process
> >> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
> >> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
> >> >> 8, responseRequired = false, messageId =
> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination =
> >> >> null,
> >> >> ori
> >> >> ginalTransactionId = null, producerId =
> >> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
> >> >> queue://queue.samordn
> >> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
> >> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
> >> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
> >> >> persistent = false, type = , priority = 0, groupID =
> >> >> null, groupSequence = 0, targetConsumerId = null, compressed =
> false,
> >> >> userID = null, content = null, marshalledProperti
> >> >> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
> >> >> properties
> >> >> = null, readOnlyProperties = true, readOnly
> >> >> Body = true, droppable = false, text = <?xml version="1.0"
> >> >> encoding="UTF-8"?>
> >> >> <TPForholdHendelse>
> >> >> <type>Opprett</type>
> >> >> <ordning>1015</ordning>
> >> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
> >> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
> >> >> </TPForholdHendelse>
> >> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
> >> >>
> >> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> org.apache.camel.processor.Logger log
> >> >> SEVERE: Failed delivery for exchangeId:
> >> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
> >> >> processor:
> >> >> Trace
> >> >> Interceptor[To[ref:tpforholdArbeidskoe]]
> >> >>
> >> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
> >> >> org.apache.camel.processor.Logger process
> >> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
> >> Pattern:InOnly
> >> >> ,
> >> >> Headers:{JMSTimestamp=1245251480860, org.apa
> >> >> che.camel.MultiParameterArray=false, JMSType=,
> >> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
> >> JMSReplyTo=null,
> >> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
> >> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
> >> >> Redelivered=false,
> >> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
> >> >> JMSDeliveryMode=2, JMSCorrelationID=, J
> >> >> MSPriority=4} , BodyType:null , Body:null
> >> >> ---------------------------------------------------
> >> >>
> >> >> Anyone know the reason why we lose the message body?
> >> >>
> >> >> - Rune
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Claus Ibsen
> >> > Apache Camel Committer
> >> >
> >> > Open Source Integration: http://fusesource.com
> >> > Blog: http://davsclaus.blogspot.com/
> >> > Twitter: http://twitter.com/davsclaus
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Claus Ibsen
> > Apache Camel Committer
> >
> > Open Source Integration: http://fusesource.com
> > Blog: http://davsclaus.blogspot.com/
> > Twitter: http://twitter.com/davsclaus
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Message body lost when message moved by exception clause
Posted by RuneB <ru...@spk.no>.
A couple of more points:
* 1.6.0 behaves like 1.6.1, as far as I can tell.
* Loss of message body only occurs if *unmarshalling has taken place*. We've
an element like this:
<unmarshal>
<jaxb prettyPrint="true"
contextPath="no.spk.felles.domene.melding" />
</unmarshal>
If I replace this element (and the bean calls it's for), with a bean call
that simply throws an exception,
the message body will be intact after the message has been moved by
onException.
- Rune
Claus Ibsen-2 wrote:
>
> On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
>
>>
>> Hi,
>>
>> The message body is definitely there when the message is consumed from
>> the
>> original queue.
>>
>> It's in the moving to the destination queue, as a result of an exception,
>> that the message body is lost.
>>
>> I'm inspecting the destination queue using the ActiveMQ admin tool. Also,
>> we
>> have a bean that in turn consumes the destination queue; debugging this
>> bean
>> confirms that the body is lost.
>>
>> I'll get back to you about the other things you asked.
>
>
> Cool. I will be out of office in a hour or so, but will be back on monday.
>
>
>
>>
>>
>> - Rune
>>
>>
>>
>> Claus Ibsen-2 wrote:
>> >
>> > Hi
>> > No we have not have this reported before.
>> > Could you create a small unit test that demonstrates this bug / issue?
>> >
>> > Do you say you loose the body when you consume it from the JMS queue?
>> > Or do you lose the body before its sent to the JMS queue?
>> > eg when you use a JMS queue browser can you see the body?
>> >
>> > Can you try with 1.6.0 also. That would help narrow down the number of
>> > code
>> > changes in between.
>> >
>> >
>> >
>> >
>> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>> >
>> >>
>> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception
>> clauses
>> >> such
>> >> as this one
>> >>
>> >> <onException>
>> >> <exception>my.package.SomeException</exception>
>> >> <redeliveryPolicy maximumRedeliveries="0" />
>> >> <handled>
>> >> <constant>true</constant>
>> >> </handled>
>> >> <to ref="tpforholdArbeidskoe" />
>> >> </onException>
>> >>
>> >> cause the message body to be *empty* after the message has been moved
>> to
>> >> tpforholdArbeidskoe.
>> >>
>> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the route's
>> >> from-endpoint).
>> >>
>> >> The following trace may be of relevance:
>> >> ---------------------------------------------------
>> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> org.apache.camel.component.jms.JmsProducer process
>> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
>> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
>> >> 8, responseRequired = false, messageId =
>> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination =
>> >> null,
>> >> ori
>> >> ginalTransactionId = null, producerId =
>> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
>> >> queue://queue.samordn
>> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
>> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
>> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
>> >> persistent = false, type = , priority = 0, groupID =
>> >> null, groupSequence = 0, targetConsumerId = null, compressed = false,
>> >> userID = null, content = null, marshalledProperti
>> >> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
>> >> properties
>> >> = null, readOnlyProperties = true, readOnly
>> >> Body = true, droppable = false, text = <?xml version="1.0"
>> >> encoding="UTF-8"?>
>> >> <TPForholdHendelse>
>> >> <type>Opprett</type>
>> >> <ordning>1015</ordning>
>> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
>> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
>> >> </TPForholdHendelse>
>> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>> >>
>> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> org.apache.camel.processor.Logger log
>> >> SEVERE: Failed delivery for exchangeId:
>> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
>> >> processor:
>> >> Trace
>> >> Interceptor[To[ref:tpforholdArbeidskoe]]
>> >>
>> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
>> >> org.apache.camel.processor.Logger process
>> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
>> Pattern:InOnly
>> >> ,
>> >> Headers:{JMSTimestamp=1245251480860, org.apa
>> >> che.camel.MultiParameterArray=false, JMSType=,
>> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null,
>> JMSReplyTo=null,
>> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
>> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
>> >> Redelivered=false,
>> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
>> >> JMSDeliveryMode=2, JMSCorrelationID=, J
>> >> MSPriority=4} , BodyType:null , Body:null
>> >> ---------------------------------------------------
>> >>
>> >> Anyone know the reason why we lose the message body?
>> >>
>> >> - Rune
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Claus Ibsen
>> > Apache Camel Committer
>> >
>> > Open Source Integration: http://fusesource.com
>> > Blog: http://davsclaus.blogspot.com/
>> > Twitter: http://twitter.com/davsclaus
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24092993.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Jun 18, 2009 at 10:51 AM, RuneB <ru...@spk.no> wrote:
>
> Hi,
>
> The message body is definitely there when the message is consumed from the
> original queue.
>
> It's in the moving to the destination queue, as a result of an exception,
> that the message body is lost.
>
> I'm inspecting the destination queue using the ActiveMQ admin tool. Also,
> we
> have a bean that in turn consumes the destination queue; debugging this
> bean
> confirms that the body is lost.
>
> I'll get back to you about the other things you asked.
Cool. I will be out of office in a hour or so, but will be back on monday.
>
>
> - Rune
>
>
>
> Claus Ibsen-2 wrote:
> >
> > Hi
> > No we have not have this reported before.
> > Could you create a small unit test that demonstrates this bug / issue?
> >
> > Do you say you loose the body when you consume it from the JMS queue?
> > Or do you lose the body before its sent to the JMS queue?
> > eg when you use a JMS queue browser can you see the body?
> >
> > Can you try with 1.6.0 also. That would help narrow down the number of
> > code
> > changes in between.
> >
> >
> >
> >
> > On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
> >
> >>
> >> After upgrading from 1.5.0 to 1.6.1, we find that that exception clauses
> >> such
> >> as this one
> >>
> >> <onException>
> >> <exception>my.package.SomeException</exception>
> >> <redeliveryPolicy maximumRedeliveries="0" />
> >> <handled>
> >> <constant>true</constant>
> >> </handled>
> >> <to ref="tpforholdArbeidskoe" />
> >> </onException>
> >>
> >> cause the message body to be *empty* after the message has been moved to
> >> tpforholdArbeidskoe.
> >>
> >> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the route's
> >> from-endpoint).
> >>
> >> The following trace may be of relevance:
> >> ---------------------------------------------------
> >> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
> >> org.apache.camel.component.jms.JmsProducer process
> >> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
> >> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
> >> 8, responseRequired = false, messageId =
> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination =
> >> null,
> >> ori
> >> ginalTransactionId = null, producerId =
> >> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
> >> queue://queue.samordn
> >> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
> >> 1245251471047, arrival = 0, brokerInTime = 124525147106
> >> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
> >> persistent = false, type = , priority = 0, groupID =
> >> null, groupSequence = 0, targetConsumerId = null, compressed = false,
> >> userID = null, content = null, marshalledProperti
> >> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
> >> properties
> >> = null, readOnlyProperties = true, readOnly
> >> Body = true, droppable = false, text = <?xml version="1.0"
> >> encoding="UTF-8"?>
> >> <TPForholdHendelse>
> >> <type>Opprett</type>
> >> <ordning>1015</ordning>
> >> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
> >> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
> >> </TPForholdHendelse>
> >> }] with destination: queue.samordning.TPForholdTilArbeidskoe
> >>
> >> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
> >> org.apache.camel.processor.Logger log
> >> SEVERE: Failed delivery for exchangeId:
> >> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
> >> processor:
> >> Trace
> >> Interceptor[To[ref:tpforholdArbeidskoe]]
> >>
> >> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
> >> org.apache.camel.processor.Logger process
> >> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(),
> Pattern:InOnly
> >> ,
> >> Headers:{JMSTimestamp=1245251480860, org.apa
> >> che.camel.MultiParameterArray=false, JMSType=,
> >> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null, JMSReplyTo=null,
> >> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
> >> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
> >> Redelivered=false,
> >> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
> >> JMSDeliveryMode=2, JMSCorrelationID=, J
> >> MSPriority=4} , BodyType:null , Body:null
> >> ---------------------------------------------------
> >>
> >> Anyone know the reason why we lose the message body?
> >>
> >> - Rune
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Claus Ibsen
> > Apache Camel Committer
> >
> > Open Source Integration: http://fusesource.com
> > Blog: http://davsclaus.blogspot.com/
> > Twitter: http://twitter.com/davsclaus
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Message body lost when message moved by exception clause
Posted by RuneB <ru...@spk.no>.
Hi,
The message body is definitely there when the message is consumed from the
original queue.
It's in the moving to the destination queue, as a result of an exception,
that the message body is lost.
I'm inspecting the destination queue using the ActiveMQ admin tool. Also, we
have a bean that in turn consumes the destination queue; debugging this bean
confirms that the body is lost.
I'll get back to you about the other things you asked.
- Rune
Claus Ibsen-2 wrote:
>
> Hi
> No we have not have this reported before.
> Could you create a small unit test that demonstrates this bug / issue?
>
> Do you say you loose the body when you consume it from the JMS queue?
> Or do you lose the body before its sent to the JMS queue?
> eg when you use a JMS queue browser can you see the body?
>
> Can you try with 1.6.0 also. That would help narrow down the number of
> code
> changes in between.
>
>
>
>
> On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>
>>
>> After upgrading from 1.5.0 to 1.6.1, we find that that exception clauses
>> such
>> as this one
>>
>> <onException>
>> <exception>my.package.SomeException</exception>
>> <redeliveryPolicy maximumRedeliveries="0" />
>> <handled>
>> <constant>true</constant>
>> </handled>
>> <to ref="tpforholdArbeidskoe" />
>> </onException>
>>
>> cause the message body to be *empty* after the message has been moved to
>> tpforholdArbeidskoe.
>>
>> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the route's
>> from-endpoint).
>>
>> The following trace may be of relevance:
>> ---------------------------------------------------
>> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
>> org.apache.camel.component.jms.JmsProducer process
>> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
>> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
>> 8, responseRequired = false, messageId =
>> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination =
>> null,
>> ori
>> ginalTransactionId = null, producerId =
>> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
>> queue://queue.samordn
>> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
>> 1245251471047, arrival = 0, brokerInTime = 124525147106
>> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
>> persistent = false, type = , priority = 0, groupID =
>> null, groupSequence = 0, targetConsumerId = null, compressed = false,
>> userID = null, content = null, marshalledProperti
>> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
>> properties
>> = null, readOnlyProperties = true, readOnly
>> Body = true, droppable = false, text = <?xml version="1.0"
>> encoding="UTF-8"?>
>> <TPForholdHendelse>
>> <type>Opprett</type>
>> <ordning>1015</ordning>
>> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
>> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
>> </TPForholdHendelse>
>> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>>
>> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
>> org.apache.camel.processor.Logger log
>> SEVERE: Failed delivery for exchangeId:
>> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure
>> processor:
>> Trace
>> Interceptor[To[ref:tpforholdArbeidskoe]]
>>
>> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
>> org.apache.camel.processor.Logger process
>> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(), Pattern:InOnly
>> ,
>> Headers:{JMSTimestamp=1245251480860, org.apa
>> che.camel.MultiParameterArray=false, JMSType=,
>> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null, JMSReplyTo=null,
>> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
>> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
>> Redelivered=false,
>> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
>> JMSDeliveryMode=2, JMSCorrelationID=, J
>> MSPriority=4} , BodyType:null , Body:null
>> ---------------------------------------------------
>>
>> Anyone know the reason why we lose the message body?
>>
>> - Rune
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088903.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message body lost when message moved by exception clause
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
No we have not have this reported before.
Could you create a small unit test that demonstrates this bug / issue?
Do you say you loose the body when you consume it from the JMS queue?
Or do you lose the body before its sent to the JMS queue?
eg when you use a JMS queue browser can you see the body?
Can you try with 1.6.0 also. That would help narrow down the number of code
changes in between.
On Thu, Jun 18, 2009 at 10:23 AM, RuneB <ru...@spk.no> wrote:
>
> After upgrading from 1.5.0 to 1.6.1, we find that that exception clauses
> such
> as this one
>
> <onException>
> <exception>my.package.SomeException</exception>
> <redeliveryPolicy maximumRedeliveries="0" />
> <handled>
> <constant>true</constant>
> </handled>
> <to ref="tpforholdArbeidskoe" />
> </onException>
>
> cause the message body to be *empty* after the message has been moved to
> tpforholdArbeidskoe.
>
> (tpforholdArbeidskoe is a message queue on ActiveMQ, as is the route's
> from-endpoint).
>
> The following trace may be of relevance:
> ---------------------------------------------------
> 17:11:20,844 ERROR [STDERR] 17.jun.2009 17:11:20
> org.apache.camel.component.jms.JmsProducer process
> WARNING: Disabling JMSReplyTo as this Exchange is not OUT capable:
> Exchange[JmsMessage: ActiveMQTextMessage {commandId =
> 8, responseRequired = false, messageId =
> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1:4, originalDestination = null,
> ori
> ginalTransactionId = null, producerId =
> ID:vmutvjee1-b58-2757-1245247294282-2:3:1:1, destination =
> queue://queue.samordn
> ing.TPForhold, transactionId = null, expiration = 0, timestamp =
> 1245251471047, arrival = 0, brokerInTime = 124525147106
> 3, brokerOutTime = 1245251471063, correlationId = , replyTo = null,
> persistent = false, type = , priority = 0, groupID =
> null, groupSequence = 0, targetConsumerId = null, compressed = false,
> userID = null, content = null, marshalledProperti
> es = null, dataStructure = null, redeliveryCounter = 0, size = 0,
> properties
> = null, readOnlyProperties = true, readOnly
> Body = true, droppable = false, text = <?xml version="1.0"
> encoding="UTF-8"?>
> <TPForholdHendelse>
> <type>Opprett</type>
> <ordning>1015</ordning>
> <datKundeFoedtNum>xxxxxxx</datKundeFoedtNum>
> <ideKundePrsnr>xxxxxx</ideKundePrsnr>
> </TPForholdHendelse>
> }] with destination: queue.samordning.TPForholdTilArbeidskoe
>
> 17:11:20,860 ERROR [STDERR] 17.jun.2009 17:11:20
> org.apache.camel.processor.Logger log
> SEVERE: Failed delivery for exchangeId:
> ID-vmutvjee1-b58/3030-1245251235079/0-0. Handled by the failure processor:
> Trace
> Interceptor[To[ref:tpforholdArbeidskoe]]
>
> 17:11:20,875 ERROR [STDERR] 17.jun.2009 17:11:20
> org.apache.camel.processor.Logger process
> INFO: ID-vmutvjee1-b58/3030-1245251235079/2-1 -> choice(), Pattern:InOnly ,
> Headers:{JMSTimestamp=1245251480860, org.apa
> che.camel.MultiParameterArray=false, JMSType=,
> org.apache.camel.RedeliveryCounter=0, JMSXGroupID=null, JMSReplyTo=null,
> JMSDestination=queue://queue.samordning.TPForholdTilArbeidskoe,
> JMSRedelivered=false, JMSExpiration=0, org.apache.camel.
> Redelivered=false,
> JMSMessageID=ID:vmutvjee1-b58-3023-1245251233625-0:642:1:1:1,
> JMSDeliveryMode=2, JMSCorrelationID=, J
> MSPriority=4} , BodyType:null , Body:null
> ---------------------------------------------------
>
> Anyone know the reason why we lose the message body?
>
> - Rune
>
> --
> View this message in context:
> http://www.nabble.com/Message-body-lost-when-message-moved-by-exception-clause-tp24088536p24088536.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus