[
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
