users@glassfish.java.net

Re: JMS: Queue-Ordering

From: <jmilkiewicz_at_gmail.com>
Date: Thu, 8 Mar 2012 14:34:37 +0100

Hi

What i understand from your mail is that because of mdc.setRollbackOnly()
message1 is redelivered, but till the time you reprocess it again you do
not want following messages i.e message 2 and 3 to be delivered.
I do not think this kind of processing is doable in JMS out of the box.
Maybe you could try some tricks with configuring retries but not sure.
Weblogic JMS provides some extensions over pure JMS like Unit-Of-Work but
again not sure if any of these will meet your requirements.

Regarding your description it sounds as you need a global order between
messages.
JMS supports processing messages in the same order as they were put to
queue (assuming all messages are given the same priority) but it is not
always a case (i remember these kind of bugs)
Regarding you can not start processing message in case a prior
message/messages were not processed it can be quite hard to do in MDB,
since temporary/permanent inability to process a message means you need to
rollback a message and put it at head of queue. Even if you managed to
configure JMS that way, you still would need to find a way to distinguish
between permanent and temporary failures. In case a permanent failure you
would need to stop MDB.
In case of temporary failure just reprocess a message with some sleep.

On the other side if your communication with an external resource is
idempotent (in your mail you mentioned you do 'query' so i assume the
operation is idempotent) you could try to wrap it with a try/catch/sleep
and retry it a number of times till you decide external resource is down
and you need to shutdown (if it is possible to do a shutdown) MDB and
notify administrator about the problem.

br Jakub

P.S here you have a link to someone (working with Spring not Glassfish) who
had the same/similar requirements.




If you want to process messages as a group

W dniu 8 marca 2012 12:32 użytkownik Nigel Deakin
<nigel.deakin_at_oracle.com>napisał:

> Patrick,
>
> Asking your question here is fine :-)
>
> Please help me understand your question:
>
> You have a single MDB instance processing messages from a queue.
> The MDB receives message 1. This calls setRollbackOnly() and returns.
>
> You are reporting that the MDB does not receive message 1 again (which is
> the behaviour you want) but instead receives message 2 and then message 3.
>
> Have I got this right?
>
> Does message 1 get redelivered eventually?
>
> Nigel
>
>
>
> On 07/03/2012 13:13, forums_at_java.net wrote:
>
>> Hi all,
>>
>> I'm currently evaluating glassfish and its jms-component for a project
>> where
>> two requirements have to be fullfilled. The queue has to be orderd and
>> there
>> may be only one consumer. This is important since messages might depend on
>> each other.
>>
>> By configuring a singleton-bean-pool I currently have one MDB processing
>> the
>> messages, wich is quite good but has one bad issue: I have to query an
>> external resource and this query might fail. It is unlikely, but possible,
>> that a couple of messages are delivered to the queue and the first one
>> fails
>> to query the external resource. In that case I want to abort and reprocess
>> this "message 1" until it succeeds and I do NOT want to process "message
>> 2"
>> or even "message 3", which made it to the queue as well.
>>
>> However, that's precisely that happens when I detect the issue and invoke
>> "mdc.setRollbackOnly();" on "message 1".
>>
>> I should be able to dodge MDB and instead create a standalone-client
>> performing the required processing. However, I'm not sure that would solve
>> the ordering issue? And since it would be very closely coupled, a
>> MDB-solution would be the preferred option. Or there might be
>> options/properties of queues in Glassfish which I'm not aware of yet. Or I
>> might have to evaluate alternatives, but that would be the worst option.
>> :-(
>>
>> I'm quite confused by the available glassfish-homepages and available
>> documentation, quite a lot of links are leading to non-existent URLs.
>> Looks
>> like quite a bit of documentation still has issues with Oracle aquiring
>> Sun?
>> I'm not even sure I'm asking in the right forum, so feel free to give me
>> some
>> kicking, as long as you point me in the right direction. ;-)
>>
>> Yours,
>>
>> Patrick.
>>
>>
>> --
>>
>> [Message sent by forum member 'pvdh']
>>
>> View Post: http://forums.java.net/node/**884067<http://forums.java.net/node/884067>
>>
>>
>>