Bug 1013884 - Do not apply redeliveryDelay milliseconds after consumer close
Do not apply redeliveryDelay milliseconds after consumer close
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ (Show other bugs)
All Linux
unspecified Severity high
: ER6
: EAP 6.2.0
Assigned To: Clebert Suconic
Martin Svehla
Russell Dickenson
Depends On: 1016141
Blocks: 1020963
  Show dependency treegraph
Reported: 2013-09-30 21:47 EDT by Tyronne Wickramarathne
Modified: 2013-12-15 11:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1020963 (view as bug list)
Last Closed: 2013-12-15 11:48:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
csuconic: needinfo+
csuconic: needinfo+

Attachments (Terms of Use)

  None (edit)
Description Tyronne Wickramarathne 2013-09-30 21:47:54 EDT
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:

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-09-30 21:50:54 EDT

Testcase included
Comment 2 Martin Svehla 2013-10-17 08:17:09 EDT
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.