Bug 1013884 - Do not apply redeliveryDelay milliseconds after consumer close
Summary: Do not apply redeliveryDelay milliseconds after consumer close
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ
Version: 6.1.0
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ER6
: EAP 6.2.0
Assignee: Clebert Suconic
QA Contact: Martin Svehla
Russell Dickenson
URL:
Whiteboard:
Depends On: 1016141
Blocks: 1020963
TreeView+ depends on / blocked
 
Reported: 2013-10-01 01:47 UTC by Tyronne Wickramarathne
Modified: 2013-12-15 16:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1020963 (view as bug list)
Environment:
Last Closed: 2013-12-15 16:48:30 UTC
Type: Bug
Embargoed:
csuconic: needinfo+
csuconic: needinfo+


Attachments (Terms of Use)

Description Tyronne Wickramarathne 2013-10-01 01:47:54 UTC
Description of problem:
When a consumer performs a graceful shutdown on the connection, the buffered messages aren't returned back. But attempts to redeliver to the same thread as per the redelivery-delay configuration. 

This causes a message starvation for the next immediate client.
Please refer https://issues.jboss.org/browse/HORNETQ-1259 for more information


Version-Release number of selected component (if applicable):
HornetQ-2.3.1, JBoss-EAP-6.1.1

How reproducible:
Always

Steps to Reproduce:
1. Create a destination, queue/M on HornetQ
2. Send about 200 messages to queue/M
3. Please run a JMS consumer to sonsume 2-3 messages and perform a graceful shutdown
4. You would see xyz number of pending/scheduled messages allocated for the JMS client who has terminated gracefully
5. Start the another JMS client client, this second JMS client won't be able to consume messages for 60 seconds. In other words, the messages in the destination have been scheduled for the terminated client and aren't available for this client.
5. The JMS broker retains messages as per the configured redelivery-delay attribute.


Actual results:
The messages aren't available for the next immediate JMS client

Expected results:
The messages should be available for the next immediate client irrespective of the value been specified for redelivery-delay

Additional info:

Comment 1 Clebert Suconic 2013-10-01 01:50:54 UTC
https://github.com/hornetq/hornetq/pull/1313

Testcase included

Comment 2 Martin Svehla 2013-10-17 12:17:09 UTC
Tested with EAP 6.2.0.ER6 / HornetQ 2.3.9.Final


Note You need to log in before you can comment on or make changes to this bug.