Hi,
I agree with David poison message is pain area but its more related to
design insted of API .
Every application has diffrent need and want to handle poison message in
diffrent way.
1 ) After 3 or 5 or configurable retry discard message.
2) After 3 or 5 or configurable time move error message to error queue and
based on your logic you can process it.
If we can update few design approch to handle poison message in doc ,it
might be helpful for jms user.
Regards,
Vaquar khan
On 12 Aug 2015 05:20, "David Heffelfinger" <dheffelfinger_at_gmail.com> wrote:
> New guy here, apologies if I'm breaking any rules, if this is the case
> please let me know.
>
> In any case, I read Nigel's "More flexible JMS MDBs (Version 2)" document
> at https://java.net/projects/jms-spec/pages/JMSListener2 and have some
> comments.
>
> I like a lot of the ideas that have been suggested.
>
> Most of the ideas suggested will result in a better, easier to use APIs,
> which is great, however, the following particular suggestions addresses
> what, in my experience, is one of the biggest pain points when using MDB's:
>
> "The JMS provider should detect repeated attempts to redeliver the same
> message to a MDB. Such messages may either be
> discarded or delivered to a provider-specific dead message queue. (Note
> that this not completely new to JMS: JMS 2.1
> section 8.7 refers to a JMS provider "giving up" after a message has been
> redelivered a certain number of times)."
>
> I am actually working on a project right now that uses JMS extensively,
> and "JMS Message Poisoning" has been a problem
> that has been not that easy to solve. Essentially if there is an exception
> when handling a message, the message is put
> back in the queue then immediately consumed again by the same MDB, again
> the exception is thrown, the message goes back
> in the queue, essentially in an infinite loop. It would be great if the
> spec provided a standard, easily configurable way to deal with this
> situation. If I may, I think it would be nice that this particular
> suggestion does not "fall through the cracks" (i.e. make it a high
> priority).
>
> Just my two cents.
>
> David
> --
> http://ensode.net - A Guide to Java, Linux and Other Technology Topics
> My Books: http://www.packtpub.com/authors/profiles/david-heffelfinger
> My Video Training:
> http://www.packtpub.com/java-ee-development-with-netbeans-7/video
> Follow me on Twitter: https://twitter.com/ensode
>