Hi John, please see inline.
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.
>
IMHO this will lead to situations where one message can actually block
the queue for an extended period of time. if you look at the JMSBC from
OpenESB the JMS BC has redelivery semantics, where messages that cause
business processes to fail can either be deleted, throw an error,
redirected to different destinations or suspend the process instance.
If you use the JMSJCA resource adapter (
https://jmsjca.dev.java.net/)
the retry semantics can be configured with for instance an increasing
time between retries before being picked off the queue after a defined
number of retries. The message can be delivered to an alternate queue
(say mq.sys.dmq (the dead message queue) which can be further listened
to to provide the alerting mechanism you describe.
Is message ordering important to you? If this is the case, the scenario
above with one message blocking message handling is very valid since
you'd have to this using only one consume thread. (not very scalable)
> 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.
>
In batch oriented scenarios like these you can quickly come into
situations where the queue builds up to sizes beyond what can be
processed within the timeslot that you allocate. This wil lead to an
ever incrising backlog of messages unless traffic slows.
> 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 :)
>
Remember that JMS is meant as an asynchronous delivery technique, which
as it promotes loose coupling alllows you to scle better than
synchronous systems.
Design suggestion:
If you just want to regularly get messages of a queue I'd forgo the MDB
listening to the queue and build a simple TimeerEJB. This timer triggers
a separate EJB (in my ideal designs to enable seperation between the
timer event and the action(s) performed.) The Triggered EJB creates a
new JMS session, reads any number of messages of the queue.
.trond
>
> Thanks again.
>
>
> John
> [Message sent by forum member 'johnstv' (johnstevens3_at_hotmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=366708
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>