Issue Details (XML | Word | Printable)

Key: GLASSFISH-7717
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: David Zhao
Reporter: friedeks
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Wrong handling of RuntimeExceptions in JMS cluster

Created: 14/Apr/09 11:32 PM   Updated: 02/Nov/12 03:20 AM
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0

Time Tracking:
Not Specified

Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 7,717
Status Whiteboard:

v3_exclude, v2.1.1_exclude

Tags: bj-reviewed
Participants: David Zhao, Ed Bratt, friedeks, Satish Kumar, Simon Meng and Tom Mueller


 Description  « Hide

I installed a v2.1 cluster with two nodes and set up a default jms
ConnectionFactory and logical + physical queue.
I composed a testcase with one MDB doing nothing but throwing a RuntimeException.
The MDB was configured with "EndpointExceptionRedeliveryAttempts=5" and deployed
to the cluster.
A JavaSE Client uses JNDI to send 10000 transactional messages to the queue.
The load gets distributed evenly between the two cluster instances. Instance one
behaves as expected and retries 5 times before moving the messages to DMQ.
Instance two instead seems to ignore EndpointExceptionRedeliveryAttempts and
keeps trying to deliver the bad messages. Instance two loops forever using a lot
of CPU. The Queue shows around 5000 "Not ACK" messages.

The same testcase runs flawlessly in a non-clustered environment.



Satish Kumar added a comment - 09/Sep/09 04:25 AM

This is a v2.1 issue not relevant for V3. Hence adding 'v3_exclude' in the
status whiteboard.


Ed Bratt added a comment - 15/Oct/09 04:26 PM

Will not fix in v2.1.1


Tom Mueller added a comment - 06/Mar/12 09:55 PM

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.


Simon Meng added a comment - 24/Oct/12 09:16 AM

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?


Simon Meng added a comment - 02/Nov/12 02:56 AM - edited

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.