It was discovered that if Session.nextReceiver() with IMMEDIATE duration was called while the connection to the broker was being lost (due to a network issue, for example) , the method could fail to raise the expected MessagingException. This could cause a client application to not be notified that the connection has shut down, so the application can fail to reconnect. Session.nextReceiver now reliably returns the desired exception if the connection is closed. The client application gets the exception and can take appropriate action.
Description of problem:
Invoking Session.nextReceiver() with IMMEDIATE duration when the broker is just dropping the connection (i.e. during its shutdown), the method does not raise MessagingException on faster machines (some timing is crucial).
Version-Release number of selected component (if applicable):
0.18-31
How reproducible:
100% (on faster machines)
Steps to Reproduce:
1. Compile attached program. Dont find a logic in the tight loop, it just serves as a reproducer.
2. service qpidd start; qpid-config add queue q
3. ./qpid-read <broker> q 10 &
4. service qpidd stop
5. check qpid-read process
Actual results:
qpid-read should be still running, no exception caught
Expected results:
MessagingException is raised, qpid-read terminated
Additional info:
Hey Mike
I got an Errata advisory update for this and noted this bug was added.
Would this require some CCFR to be provided, and the MRG 2 Release Notes doc subsequently updated?
Cheers
J
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2014-1682.html