|
Problem(Abstract) |
Depending on the settings used with Java™ Message Service
(JMS), it is possible for the order of messages in the queue to change
after a rollback. |
|
|
|
Cause |
With MQSeries JMS, the behavior for backed-out messages is
to continue down the queue delivering the next available messages and then
go back to the beginning and try to deliver the backed-out message again.
What results is 1,2,4,5,3 behavior with MQ JMS. |
|
|
Resolving the
problem |
The following scenario shows how the order of messages in
a queue might change:
- Send a JMS message to a queue with listener port and Message Driven
Bean (MDB) bound.
- Use simple content for five messages, such as numbers that increment
from 1-to-5.
- Set transaction attribute for CMT to Required.
- View message contents and invoke setRollbackOnly() when processing
message ofvalue=3.
- Review the queue after the message is rolled back:
- The order of the message-processing is not same.
- The desired order is 1>2>3>4>5.
- The actual order is 1>2>4>5>3.
A solution is to add NON.ASF.RECEIVE.TIMEOUT with a value of 60000 to
the custom properties of the message listener service for all the servers
hosting MDBs.
Using NON.ASF.RECEIVE.TIMEOUT changes the behavior for all MDB
Listeners to use a non-ASF mode of operation:
- Rather than the ASF listener browsing mechanism, each
MDBListener uses a set of threads that each receive messages synchronously
with a timeout. In other words, they poll for messages.
- Performance/scaling characteristics are changed. If you
set MaxSessions to 1 for synchronous receivers, the behavior is the same
as a single JMS Receiver doing MQGETs under the covers.
- As a result, after the next MQGET the previously
rolled-back message is available again.
|
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|