You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Created) (JIRA)" <ji...@apache.org> on 2012/01/31 11:22:10 UTC

[jira] [Created] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

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


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

        

[jira] [Updated] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Babak Vahdat (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Babak Vahdat updated CAMEL-4961:
--------------------------------

    Attachment: JMSTransactionIsTransactedRedeliveredTest.jpeg

It did pass on my Windows XP box (see the attached screenshot)
                
> 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: 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Claus Ibsen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196889#comment-13196889 ] 

Claus Ibsen commented on CAMEL-4961:
------------------------------------

Yeah this has been a bit of a pain before, as people had a harder time to correlate the messages from Camel.
Also the MDC logging now has messageId as key, so you can use that as well.

There is a slight API change in Exchange, but that should not matter as there is only one impl of that, the DefaultExchange.
So I focused on not having to make API changes to Message, so we can backport this to Camel 2.9 as well.
                
> 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.10.0
>
>
> 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Babak Vahdat (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197687#comment-13197687 ] 

Babak Vahdat commented on CAMEL-4961:
-------------------------------------

Now it looks better, THANKS!
                
> 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Claus Ibsen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197661#comment-13197661 ] 

Claus Ibsen commented on CAMEL-4961:
------------------------------------

Ah I made a mistake, it was the else part I tested. The if part can fail. I have improved the test.
                
> 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

        

[jira] [Updated] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Babak Vahdat (Updated) (JIRA)" <ji...@apache.org>.
     [ 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Claus Ibsen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196920#comment-13196920 ] 

Claus Ibsen commented on CAMEL-4961:
------------------------------------

The test still failed, the mocks is not satisified, i did a try for that before committing.
                
> 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
>
>
> 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Babak Vahdat (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196917#comment-13196917 ] 

Babak Vahdat commented on CAMEL-4961:
-------------------------------------

Hi Claus,

Just spotted a well known sharp corner usage of JUnit in [1]!

The problem is that if you assert on something which is *not* running on the main thread you will not realize if a AssertionError is thrown by JUnit! This is a well known JUnit bottleneck and there're some workarounds for that like in [2].

The Test will *still* pass if you would define MyProcessor as the following (note the change by the assertFalse() statement I did):

{code}
    public static class MyProcessor implements Processor {
        private int count;

        public void process(Exchange exchange) throws Exception {
            ++count;

            // the first is not redelivered
            if (count == 1) {
                assertFalse("Should not be transacted redelivered", true);
            } else {
                assertTrue("Should be transacted redelivered", exchange.isTransactedRedelivered());
            }

            if (count < 3) {
                throw new IllegalArgumentException("Forced exception");
            }
            exchange.getIn().setBody("Bye World");
            exchange.getIn().setHeader("count", count);
        }
    }
{code}   


[1] https://svn.apache.org/repos/asf/camel/trunk/components/camel-jms/src/test/java/org/apache/camel/component/jms/tx/JMSTransactionIsTransactedRedeliveredTest.java
[2] http://stackoverflow.com/questions/2596493/junit-assert-in-thread-throws-exception

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

        

[jira] [Resolved] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Claus Ibsen (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-4961.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 2.9.1
    
> 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
>
>
> 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Claus Ibsen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196834#comment-13196834 ] 

Claus Ibsen commented on CAMEL-4961:
------------------------------------

Here is a sample from the TX error handler logging the rollback at WARN level.
Notice how we know can see
- if its redelivery or not
- the messageId is the same, so we can correlate
- the exchangeId is unique, but we can correlate with other logs that show the exchangeId

PS: We can also use MDC logging which offers messageId and exchangeId details etc.

{code}
2012-01-31 12:05:44,789 [sConsumer[okay]] WARN  TransactionErrorHandler        - Transaction rollback (0x34b6a6d6) redelivered(false) for (MessageId: ID:davsclaus.lan-56668-1328007944517-2:2:1:1:1 on ExchangeId: ID-davsclaus-lan-56667-1328007944001-0-3) caught: java.lang.IllegalArgumentException: Forced Exception
2012-01-31 12:05:44,797 [sConsumer[okay]] WARN  TransactionErrorHandler        - Transaction rollback (0x34b6a6d6) redelivered(true) for (MessageId: ID:davsclaus.lan-56668-1328007944517-2:2:1:1:1 on ExchangeId: ID-davsclaus-lan-56667-1328007944001-0-4) caught: java.lang.IllegalArgumentException: Forced Exception
2012-01-31 12:05:44,801 [sConsumer[okay]] WARN  TransactionErrorHandler        - Transaction rollback (0x34b6a6d6) redelivered(true) for (MessageId: ID:davsclaus.lan-56668-1328007944517-2:2:1:1:1 on ExchangeId: ID-davsclaus-lan-56667-1328007944001-0-5) caught: java.lang.IllegalArgumentException: Forced Exception
2012-01-31 12:05:44,805 [sConsumer[okay]] WARN  TransactionErrorHandler        - Transaction rollback (0x34b6a6d6) redelivered(true) for (MessageId: ID:davsclaus.lan-56668-1328007944517-2:2:1:1:1 on ExchangeId: ID-davsclaus-lan-56667-1328007944001-0-6) caught: java.lang.IllegalArgumentException: Forced Exception
2012-01-31 12:05:44,809 [sConsumer[okay]] WARN  TransactionErrorHandler        - Transaction rollback (0x34b6a6d6) redelivered(true) for (MessageId: ID:davsclaus.lan-56668-1328007944517-2:2:1:1:1 on ExchangeId: ID-davsclaus-lan-56667-1328007944001-0-7) caught: java.lang.IllegalArgumentException: Forced Exception
{code}
                
> 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.10.0
>
>
> 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

        

[jira] [Commented] (CAMEL-4961) Make TX error handler log more details such as redelivery and messageId, which allows people to better correlate messages

Posted by "Babak Vahdat (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAMEL-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196857#comment-13196857 ] 

Babak Vahdat commented on CAMEL-4961:
-------------------------------------

A great improvement for those Camel users making use of the transactional JMS, Thanks!
                
> 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.10.0
>
>
> 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