You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Stirling Chow (JIRA)" <ji...@apache.org> on 2008/02/25 23:35:17 UTC
[jira] Created: (AMQ-1601) maximumRedeliveries not honoured when
transacted session is closed without explicit rollback
maximumRedeliveries not honoured when transacted session is closed without explicit rollback
--------------------------------------------------------------------------------------------
Key: AMQ-1601
URL: https://issues.apache.org/activemq/browse/AMQ-1601
Project: ActiveMQ
Issue Type: Bug
Components: Broker, JMS client
Affects Versions: 5.1.0
Environment: Windows XP SP2, Sun JDK 1.5.0_8
Reporter: Stirling Chow
Attachments: ActiveMQTest.zip
1) Unzip attachment into a directory
2) Edit build.xml and change activemq.home to point to your ActiveMQ distribution
3) Run "ant" and observe that one of the 2 JUnit tests fail
4) Refer to test-report for information about the failure
The first JUnit test creates a temporary broker and submits a single message to the queue "test.queue". It then creates a transacted message consumer that retrieves the message, prints out details about it, and then rollsback and closes the session. Subsequent retries by the consumer verify that the message is redelivered up to the MAX_REDELIVERIES constant in RedeliveryRollbackTest.java. Finally, the test verifies that after MAX_REDELIVERIES, test.queue is empy (i.e., the message has been recognized as a poison pill).
The second JUnit test performs the same sequence of operations, but instead of explicitly rolling back the session, it just closes the session. According to the JavaDoc for javax.jms.session#close():
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/index.html
"Closing a transacted session must roll back the transaction in progress. "
In other words, I was expecting the behaviour to be the same for both test cases. However, although the delivery count is updated on the message, it continues to get delivered regardless of the MAX_REDELIVERIES setting.
ADDITIONAL CONCERN
---------------------------------
Observe the console output of the tests and note how the delivery count increments by two for the test that works, but only by one for the test that doesn't:
Attempt 1
Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=false, delivery count=1
Attempt 2
Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=3
Attempt 3
Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=5
Attempt 4
Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=7
Attempt 5
No message available.
Attempt 1
Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=false, delivery count=1
Attempt 2
Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=2
Attempt 3
Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=3
Attempt 4
Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=4
Attempt 5
Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=5
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-1601) maximumRedeliveries not honoured when
transacted session is closed without explicit rollback
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved AMQ-1601.
-----------------------------
Resolution: Fixed
Assignee: Gary Tully
this issue is resolved on trunk, see the resolution to the linked issue.
Re the test case: I made the following small changes, diff:
{code}53c53
< for (int attempt = 1; attempt <= MAX_REDELIVERIES; attempt++) {
---
> for (int attempt = 0; attempt <= MAX_REDELIVERIES; attempt++) {
59c59
< if (attempt < MAX_REDELIVERIES) {
---
> if (attempt <= MAX_REDELIVERIES) {
78c78
< for (int attempt = 1; attempt <= MAX_REDELIVERIES; attempt++) {
---
> for (int attempt = 0; attempt <= MAX_REDELIVERIES; attempt++) {
84c84
< if (attempt < MAX_REDELIVERIES) {
---
> if (attempt <= MAX_REDELIVERIES) {
{code}
as you need to exceed the max deliveries to get a null message. But with these changes it works on trunk.
> maximumRedeliveries not honoured when transacted session is closed without explicit rollback
> --------------------------------------------------------------------------------------------
>
> Key: AMQ-1601
> URL: https://issues.apache.org/activemq/browse/AMQ-1601
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
> Affects Versions: 5.1.0
> Environment: Windows XP SP2, Sun JDK 1.5.0_8
> Reporter: Stirling Chow
> Assignee: Gary Tully
> Fix For: 5.3.0
>
> Attachments: ActiveMQTest.zip
>
>
> 1) Unzip attachment into a directory
> 2) Edit build.xml and change activemq.home to point to your ActiveMQ distribution
> 3) Run "ant" and observe that one of the 2 JUnit tests fail
> 4) Refer to test-report for information about the failure
> The first JUnit test creates a temporary broker and submits a single message to the queue "test.queue". It then creates a transacted message consumer that retrieves the message, prints out details about it, and then rollsback and closes the session. Subsequent retries by the consumer verify that the message is redelivered up to the MAX_REDELIVERIES constant in RedeliveryRollbackTest.java. Finally, the test verifies that after MAX_REDELIVERIES, test.queue is empy (i.e., the message has been recognized as a poison pill).
> The second JUnit test performs the same sequence of operations, but instead of explicitly rolling back the session, it just closes the session. According to the JavaDoc for javax.jms.session#close():
> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/index.html
> "Closing a transacted session must roll back the transaction in progress. "
> In other words, I was expecting the behaviour to be the same for both test cases. However, although the delivery count is updated on the message, it continues to get delivered regardless of the MAX_REDELIVERIES setting.
> ADDITIONAL CONCERN
> ---------------------------------
> Observe the console output of the tests and note how the delivery count increments by two for the test that works, but only by one for the test that doesn't:
> Attempt 1
> Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=false, delivery count=1
> Attempt 2
> Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=3
> Attempt 3
> Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=5
> Attempt 4
> Received message id=ID:schow-desktop-4347-1203977945999-2:0:1:1:1, redelivered=true, delivery count=7
> Attempt 5
> No message available.
> Attempt 1
> Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=false, delivery count=1
> Attempt 2
> Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=2
> Attempt 3
> Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=3
> Attempt 4
> Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=4
> Attempt 5
> Received message id=ID:schow-desktop-4347-1203977945999-2:1:1:1:1, redelivered=true, delivery count=5
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.