[GLASSFISH-7717] Wrong handling of RuntimeExceptions in JMS cluster Created: 14/Apr/09 Updated: 02/Nov/12
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Operating System: Linux
I installed a v2.1 cluster with two nodes and set up a default jms
The same testcase runs flawlessly in a non-clustered environment.
|Comment by Satish Kumar [ 09/Sep/09 ]|
This is a v2.1 issue not relevant for V3. Hence adding 'v3_exclude' in the
|Comment by Ed Bratt [ 15/Oct/09 ]|
Will not fix in v2.1.1
|Comment by Tom Mueller [ 06/Mar/12 ]|
Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
|Comment by Simon Meng [ 24/Oct/12 ]|
I can't reproduce the described issue. The expected RuntimeException appeared. There is no infinite loop.
But I found other issue in my testing. When sending a message from the standalone java client to queue, the MDB behaves as expected and retries 5 times, we can see 6 RuntimeExceptions. Then the message was moved to DMQ. It looks everything works fine at this point. But when I restart domain and server, the MDB throws 6 RuntimeExceptions again. The message also enters queue and marked as "UnAck". Each time I retart domain, the MDB still throws 6 RuntimeExceptions. It looks to me the behavior is not correct. The message has been moved to the DMQ, why it is delivered again and again when domain restart?
|Comment by Simon Meng [ 02/Nov/12 ]|
The "other issue" that simeng_oracle noticed in his testing as mentioned in his above comment - that involves a transacted sender client and restart domain is a MQ bug MQ-227.