Thanks
for the input, and yes I was aware that you cannot assume any message
ordering. What I am referring to is slightly different and I'm not sure
what the spec has about MDB retry implementations. I was
expecting the retry of the message to be in the same thread as the one that
original consumed the message. This doesn't seem to be the case.
Instead, it appears that the message is just posted back onto the queue,
reconsumed at a later time in a different "thread", then rinse and repeat until
the retry threshold is met.
What
JBoss specific implementation behaviour are you referring
to?
Dustin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 7:26 AM
To: [EMAIL PROTECTED]
Subject: Antwort: RE: [JBoss-user] MDB Singleton retry semantics
The JMS specification explicitly states that no assumptions about message delivery order should be made. You have to implement you own delivery order tracking logic ( normally based on tracking the ascending message ID and usage of some kind of message buffering in case of unordered message delivery... I know that it's weird to buffer messages that are already buffered :-)
Relying on the current JBOSS specific implementation behaviour will lead to a unportable / unreliable solution.
Regards
Ulf
"Barlow, Dustin" <[EMAIL PROTECTED]>
Gesendet von: [EMAIL PROTECTED]14.08.2003 22:33
Bitte antworten an jboss-user
An: "'[EMAIL PROTECTED] '" <[EMAIL PROTECTED]>
Kopie:
Thema: RE: [JBoss-user] MDB Singleton retry semantics
I guess it isn't obvious to me why is "readahead" important in terms of
efficiency of queue message consumption. Can you elaborate?
Is it possible to configure the container to wait for the ServerSession in
this case? I have already defined a separate invoker-binding and a
container-config for this bean, so I could isolate it to just the singleton
MDB.
I am not sure that having it wait for the ServerSession and then consume the
message would solve the problem. If the retry behaviour of the container is
simply consuming the message and then pushing the message back onto the
source queue again, this still wouldn't guarantee that other messages
wouldn't be in front of that reposted message correct?
Thanks for the help,
Dustin
-----Original Message-----
From: Adrian Brock
To: [EMAIL PROTECTED]
Sent: 8/14/2003 3:11 PM
Subject: Re: [JBoss-user] MDB Singleton retry semantics
That isn't the way it currently works.
The ConnectorConsumer immediatley retrieves the next message
from the queue then waits for a ServerSession from the pool.
Once you've nacked the failed message back into the queue, it will
process the waiting message using the freed session.
It will then ask the queue for the next message which will
be the one you nacked.
To make it work the way you want the ConnectionConsumer
would have to work in the opposite order.
Instead of receiving message(s) and waiting for a
ServerSession. It would wait for a ServerSession then
receive the message.
This is obviously less efficient in the normal use case,
you lose the "readahead" of the messages.
Regards,
Adrian
On Thu, 2003-08-14 at 19:00, Barlow, Dustin wrote:
> I have a singleton CMT MDB consuming on a JMS queue with a retry
threshold
> set to 3 attempts. I made the assumption that no other messages on
the
> queue would be consumed until the current message being processed
either
> finishes and is consumed, or in the event of a container transaction
> rollback and the retry threshold is reached, the message is consumed
off the
> source queue and pushed to the DLQ.
>
> However, the behaviour I'm seeing is that on the retry, other messages
> sitting on the queue are consumed prior to the retry occurring. The
> singleton is working in terms of only one message at a time being
processed,
> however the retry semantic seems odd to me in that it appears like the
> implementation of the retry logic is just simply pushing the message
back on
> the queue to be consumed again in a different "thread" later on.
>
> Is this correct? If so, how do I change that behaviour so that no
other
> messages on the queue are triggered until the message completes its
> processing either by consumed normally, or by being consumed and
pushed to
> the DLQ once the retry threshold is reached?
>
> Dustin
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
