Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Message-driven bean acknowledgment.

 
Tanin Patsornpun
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

From the HFEJB book, it said that Container will acknowledge
the JMS server when it receive the message so JMS server can remove that message from the Queue. And if the message processing fail, the Container will tell the JMS server so the JMS server can put that message back into the queue.

But later the book say, if we use CMT in MDB and then receive a bad
message that can never commit, the JMS server will keep sending
that message to the Container. And results in a suggestion that should
use BMT to avoid this issue.

How can the JSM server keep sending that message if it is removed from
the Queue in the first place.

Sound like, the Container will sent JMS server the acknowledge only
after the message processing success. The message will be remain in the
Queue until the JMS server get the acknowledge from the Container, and it make sense with this assumption.

please correct if I went wrong.


Thanks.
 
paresh vernekar
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI,
In this case, the container will send the message to MDB and acknowledge the same to JMS provider.The JMS provider will remove the message from the queue.In case of a transaction rollback, the message will be placed back on the queue.As a result, the container will then again pick up the message and send it to an MDB, may or may not be the same instance.If the transaction rollsback again, the same process is repeated.
This is something known as 'poison message'. It depends on the JMS provider to provide some kind of configuration option to prevent this scenario.

Hope this clears your doubt

Regards,
Paresh Vernekar
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic