You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Babak Vahdat (Updated) (JIRA)" <ji...@apache.org> on 2012/02/01 08:42:58 UTC
[jira] [Updated] (CAMEL-4961) Make TX error handler log more
details such as redelivery and messageId, which allows people to better
correlate messages
[ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Babak Vahdat updated CAMEL-4961:
--------------------------------
Attachment: CAMEL-4961.patch
It did test on my Mac box as well and the test still passed where I did:
{code}
if (count == 1) {
assertFalse(true);
}
{code}
As I don't intend to change the test by myself on SVN (want to have your O.K.), I attach a patch to this ticket which resolves this false-positive behaviour.
> Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-4961
> URL: https://issues.apache.org/jira/browse/CAMEL-4961
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-jms, camel-spring
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Fix For: 2.9.1, 2.10.0
>
> Attachments: CAMEL-4961.patch, JMSTransactionIsTransactedRedeliveredTest.jpeg
>
>
> If you use a JMS route, and have transacted=true, then messages may get redelivered from the JMS broker. And currently it can be a bit tricky to see from the logs that this is a redelivered message from the JMS broker. And be able to correlate message logs, to previous message attempts.
> We need to improve this so the TransctedErrorHandler can detect the JMS redelivered message, and log that its a redelivery.
> Likewise we need to log both MessageId and Exchange, which allows people to correlate the messages.
> the MessageID will be the same for redelivered messages. While ExchangeID will always be unique.
> So for example if you redeliver the same message 5 times, you get (example simplified)
> {code}
> 1: redelivered=false, messageId=123, exchangeId=501
> 2: redelivered=true, messageId=123, exchangeId=502
> 3: redelivered=true, messageId=123, exchangeId=508
> 4: redelivered=true, messageId=123, exchangeId=509
> 5: redelivered=true, messageId=123, exchangeId=512
> 6: redelivered=true, messageId=123, exchangeId=513
> {code}
> The exchangeId is always a new UUID created, and it can jump in sequence, and hence why i showed that in the example above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira