JMS Message resent for for long processes

Question

Hi,
Currently we using Webspher App Server 6 and WSAD 6 as our development platform. We are also using Websphere MQ as our JMS server.
We have one MDB resposible for processing data extraction/migration jobs from legacy databases that can take anywhere from 20minutes to several hours to complete. Once the MDB receives the message, it starts the extraction process based on the information received in the message.
The problem is, once the job completes, it restarts again because the same message is resent to the MDB. Checking the value of getJMSRedelivered() from the message shows it is true the second time the message is received. I suspect the problem is the long time taken to execute the job, as when i test with a shorter job (1-2mins), the message is not resent. If the job takes approx more than 6mins, then the message is resent, but im not exactly sure of the actual time before the message is resent.
Im unsure where the problem lies. Currently i just check if the message is redelivered, and just ignore it, but this should not be the case, as redelivery is needed if there were any problems.
How do i avoid the redelivery? Where could the problem be ??
need help as im no expert on JMS :-)
Thanks.

Answer 1

Hi,
Currently we using Webspher App Server 6 and WSAD 6
as our development platform. We are also using
Websphere MQ as our JMS server.
We have one MDB resposible for processing data
extraction/migration jobs from legacy databases that
can take anywhere from 20minutes to several hours to
complete. Once the MDB receives the message, it
starts the extraction process based on the
information received in the message.
The problem is, once the job completes, it restarts
again because the same message is resent to the MDB.
Checking the value of getJMSRedelivered() from the
message shows it is true the second time the message
is received. I suspect the problem is the long time
taken to execute the job, as when i test with a
shorter job (1-2mins), the message is not resent. If
the job takes approx more than 6mins, then the
message is resent, but im not exactly sure of the
actual time before the message is resent.
Im unsure where the problem lies. Currently i just
check if the message is redelivered, and just ignore
it, but this should not be the case, as redelivery is
needed if there were any problems.
How do i avoid the redelivery? Where could the
problem be ??
need help as im no expert on JMS :-)
Thanks.hi buddy, hope while depyloying the you are setting the acknowledte mode to Auto-acknowledge in ejb-jar.xml file as shown below.
<ejb-jar>      
<enterprise-beans>
<message-driven>
<ejb-name>SimpleMessageBean</ejb-name>
<ejb-class>in.co.persistent.SimpleMessageBean</ejb-class>
<message-selector>MessageType = 'Fatal'OR MessageType ='Error''</message-selector>
<transaction-type>Bean</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode> <message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
</message-driven>
</enterprise-beans>
</ejb-jar>
Auto-acknowledge avoids duplicate messages because the acknowledgment is sent immediately. Therefore, the JMS provider won't send a duplicate. Most MDBs use Auto-acknowledge, to avoid processing the same message twice.
Dups-ok-acknowledge exists because it may allow a JMS provider to optimize its use of the network. In practice, though, the overhead of an acknowledgment is so small, and the frequency of communication between the MDB container and JMS provider is so high, that Dups-ok-acknowledge doesn't have a big impact on performance. Obviously, with Dups-ok-acknowledge, your MDBs must be able to handle duplicate messages correctly.