On Sun, Oct 4, 2009 at 11:36 AM, <glassfish_at_javadesktop.org> wrote:
> Thanks once again Felipe :) You're correct in that it is somewhat similar to batch-processing. Each message would be executing a specific process and if that process fails I wish the message to remain within the queue. That way the message can be read again and only be removed from the queue if that process runs successfully.
So, what condition may change in order to allow the message consuming
correct in a second trial ? It seems some external process should
change something in order to give the MDB a chance to consume
successfully the message after few trials... In theory: if a MDB was
unable to consume a message due to some infra-structure problem, the
retrial mechanism of the JMS may help. But if the problem comes from
the business side or from an external process, it is better to think
how you recover external problems than stress your configurations ...
> Ideally I'd like to have that process re-tried every hour, hence the queue will be polled every hour for the messages as opposed for them to be read as soon as they arrive. If that process is re-tried say x times then it sends a failure email and removes the message from the queue since the process always fails. That's the kind of situation I'm trying to setup up.
There are configurations in the JMS that allow you to specify a number
of retrials before to consider a message invalid - and move it to a
dead messages queue. Ideally your MDB will trigger the external
recovery process, otherwise the synchrony between the message
consuming and this external recover processes may become non effective
at all.. At the end of this blog I included some good references:
http://weblogs.java.net/blog/felipegaucho/archive/2009/09/24/handling-poison-messages-glassfish
You can also control the "transaction" of the messages consume
manually, committing or not the message consume depending on a
business logic. It is more work, but it gives your code the full
powers and fine granularity over the JMS behaviour .. perhaps you can
find your solution there... look for for JMS transactions ...
> I might be trying to use JMS in an incorrect way so I'm open to suggestions as to how I could implement my requirements in a proper way with JMS if my plan is wrong. I'm quite new to JMS so apologies if my own plan is totally wrong since I'm getting to grips with it :)
No problem, JMS is not a natural thing, you need time to absorb its
workflow .. just keep in mind that a message must be consumed as fast
as possible and "once and only once"..