RE: [JBoss-user] MDB Singleton retry semantics
No it is done that way for two reasons: 1) Symmetry - JMS doesn't care that when it invokes onMessage on the MDB container that it actually gets delivered to a pooled EJB underneath. The MDB either runs in the transactional context or suspends it (Requred or NotSupported) it never controls the transaction (RequiresNew) Understood. However, in most cases if not all, the MDB would be operating similiar to a RequiresNew since Requires will create a transaction if one doesn't exist. A CMT shouldn't exist prior to the MDB consuming the message. In what case would an MDB onMessage() actually join a pre-existing CMT? 2) There is a MaxMessages setting that allows you to process multiple messages in the same transaction/session. It would be a mistake for one of the MDB onMessages to commit the session when it still has messages to process. After thinking about this for a while, I cannot come up with any use case where you'd want to consume more then one message at a time in a transactional context. Since there is no guarantee of message ordering, or any implicit state across messages on the queue, it seems odd to me to be able to configure the number of messages that will be consumed in a single CMT. Do you have any examples of where this setting would be benefitial? Thanks for the info and help thus far, 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
On Mon, 2003-08-18 at 19:57, Barlow, Dustin wrote: No it is done that way for two reasons: 1) Symmetry - JMS doesn't care that when it invokes onMessage on the MDB container that it actually gets delivered to a pooled EJB underneath. The MDB either runs in the transactional context or suspends it (Requred or NotSupported) it never controls the transaction (RequiresNew) Understood. However, in most cases if not all, the MDB would be operating similiar to a RequiresNew since Requires will create a transaction if one doesn't exist. A CMT shouldn't exist prior to the MDB consuming the message. In what case would an MDB onMessage() actually join a pre-existing CMT? The transaction is started by JMS when it enlists the XASession's XAResource. The MDB either uses it or suspends it. 2) There is a MaxMessages setting that allows you to process multiple messages in the same transaction/session. It would be a mistake for one of the MDB onMessages to commit the session when it still has messages to process. After thinking about this for a while, I cannot come up with any use case where you'd want to consume more then one message at a time in a transactional context. Since there is no guarantee of message ordering, or any implicit state across messages on the queue, it seems odd to me to be able to configure the number of messages that will be consumed in a single CMT. Do you have any examples of where this setting would be benefitial? I don't know of anybody using this, but it could be more efficient to commit one large transaction than lots of little ones. Depends what the unit of work is and how likely one of the messages will cause a rollback. Regards, Adrian Thanks for the info and help thus far, 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
The transaction is started by JMS when it enlists the XASession's XAResource. The MDB either uses it or suspends it. When you move away from the ConnectionConsumer used in the 3.x series to the JCA1.5 MessageEndpoint approach for the 4.x series, will the above behavior still apply? 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
On Mon, 2003-08-18 at 22:14, Barlow, Dustin wrote: The transaction is started by JMS when it enlists the XASession's XAResource. The MDB either uses it or suspends it. When you move away from the ConnectionConsumer used in the 3.x series to the JCA1.5 MessageEndpoint approach for the 4.x series, will the above behavior still apply? Yes. The JMSSession delivers the message to the message endpoint. This is the same whichever method you use, you/jboss are implementing a MessageListener that is driven by a session. 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
On Sat, 2003-08-16 at 03:50, Barlow, Dustin wrote: Adrian Brock wrote: The order of work is roughly: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) releaseMDB() 6) commitSession() Why couldn't the commitSession() be done prior to releaseMDB()? Seems that if 5 and 6 were flipped, the overall behaviour would be the same. Plus with a singleton MDB setup, one could take advantage of the read-ahead optimization by having MaxSize set to a value higher then one, and still have acidity of CMT between each MDB invocation of onMessage(). Otherwise, you basically have to choke off the pooling at the session level to keep the async behaviour of the MDB at bay until the session commits. Is it done that way because another transactable resource could be enlisted for which the session would have to commit after releaseMDB()? Even if the MDB itself calls a CMT SSB, the releaseMDB() would be presumably done after the releaseSSB(). No it is done that way for two reasons: 1) Symmetry - JMS doesn't care that when it invokes onMessage on the MDB container that it actually gets delivered to a pooled EJB underneath. The MDB either runs in the transactional context or suspends it (Requred or NotSupported) it never controls the transaction (RequiresNew) 2) There is a MaxMessages setting that allows you to process multiple messages in the same transaction/session. It would be a mistake for one of the MDB onMessages to commit the session when it still has messages to process. Regards, Adrian IE: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) invoke CMT method on SSB() 5) getSSB() and enlist in tx 6) run CMT method 7) releaseSSB() 8) releaseMDB() 9) commitSession() 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
In the invoker-proxy-binding configuration I still have the following stanzas under proxy-factory-config: MaximumSize15/MaximumSize MaxMessages1/MaxMessages I wasn't exactly sure what the MaximumSize was doing so I just left it at 15. So, if I switch MaximumSize to 1, this may give me the behaviour I'm looking for? I still am a bit fuzzy on the part where if the retry implementation is just simply pushing the message back onto the source queue, then there would be no way to guarantee that no other messages would be in front of that reposted message correct? Or am I misunderstanding the MDB retry implementation in JBossMQ? Dustin -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 6:58 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] MDB Singleton retry semantics So you're wait is really on the mdb pool not the session pool. The session pool wait is still there. You probably still have the default 15 sessions in the pool? Under load, this will mean you have 1 session delivering its message and 14 waiting for the single instance mdb. Each of those 14 sessions will have a message attached. Regards, Adrian On Thu, 2003-08-14 at 21:13, Barlow, Dustin wrote: In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container transaction rollback. BTW: I'm using JBoss 3.2.2RC2. Dustin -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 8/14/2003 2:27 PM Subject: RE: [JBoss-user] MDB Singleton retry semantics How are you enforcing the singleton? -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
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/psa0013ave/direct;at.aspnet_072303_01 /01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01
RE: Antwort: RE: [JBoss-user] MDB Singleton retry semantics
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 aboutMDBretry implementations. I was expecting the retry of the messageto 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 AMTo: [EMAIL PROTECTED]Subject: Antwort: RE: [JBoss-user] MDB Singleton retry semanticsThe 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 semanticsI guess it isn't obvious to me why is "readahead" important in terms ofefficiency of queue message consumption. Can you elaborate?Is it possible to configure the container to wait for the ServerSession inthis case? I have already defined a separate invoker-binding and acontainer-config for this bean, so I could isolate it to just the singletonMDB.I am not sure that having it wait for the ServerSession and then consume themessage would solve the problem. If the retry behaviour of the container issimply consuming the message and then pushing the message back onto thesource queue again, this still wouldn't guarantee that other messageswouldn't be in front of that reposted message correct?Thanks for the help, Dustin -Original Message-From: Adrian BrockTo: [EMAIL PROTECTED]Sent: 8/14/2003 3:11 PMSubject: Re: [JBoss-user] MDB Singleton retry semanticsThat isn't the way it currently works.The ConnectorConsumer immediatley retrieves the next messagefrom the queue then waits for a ServerSession from the pool.Once you've nacked the failed message back into the queue, it willprocess the waiting message using the freed session.It will then ask the queue for the next message which willbe the one you nacked.To make it work the way you want the ConnectionConsumerwould have to work in the opposite order.Instead of receiving message(s) and waiting for aServerSession. It would wait for a ServerSession thenreceive the message.This is obviously less efficient in the normal use case,you lose the "readahead" of the messages.Regards,AdrianOn Thu, 2003-08-14 at 19:00, Barlow, Dustin wrote: I have a singleton CMT MDB consuming on a JMS queue with a retrythreshold set to 3 attempts. I made the assumption that no other messages onthe queue would be consumed until the current message being processedeither finishes and is consumed, or in the event of a container transaction rollback and the retry threshold is reached, the message is consumedoff 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 beingprocessed, however the retry semantic seems odd to me in that it appears like the implementation of the retry logic is just simply pushing the messageback 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 noother messages on the queue are triggered until the message completes its processing either by consumed normally, or by being consumed andpushed 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED]
RE: [JBoss-user] MDB Singleton retry semantics
So you're wait is really on the mdb pool not the session pool. The session pool wait is still there. You probably still have the default 15 sessions in the pool? Under load, this will mean you have 1 session delivering its message and 14 waiting for the single instance mdb. Each of those 14 sessions will have a message attached. Regards, Adrian On Thu, 2003-08-14 at 21:13, Barlow, Dustin wrote: In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container transaction rollback. BTW: I'm using JBoss 3.2.2RC2. Dustin -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 8/14/2003 2:27 PM Subject: RE: [JBoss-user] MDB Singleton retry semantics How are you enforcing the singleton? -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
Ah, of course. I forgot you can do this in JBoss! I was going to suggest that JBoss was creating multiple MDB instances and you were just seeing the effect of having them both process the incoming messages, but given your config and what Adrian has been saying it seems I would have been wrong. Rgds, Dan. -- Danny Yates -Original Message- From: Barlow, Dustin [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 21:14 To: '[EMAIL PROTECTED] ' Subject: RE: [JBoss-user] MDB Singleton retry semantics In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container transaction rollback. BTW: I'm using JBoss 3.2.2RC2. Dustin -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 8/14/2003 2:27 PM Subject: RE: [JBoss-user] MDB Singleton retry semantics How are you enforcing the singleton? -- Danny Yates -Original Message- From: Barlow, Dustin [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 19:00 To: [EMAIL PROTECTED] Subject: [JBoss-user] MDB Singleton retry semantics 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/psa0013ave/direct;at.aspnet_072303_01 /01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user _ Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority. _ --- 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https
RE: [JBoss-user] MDB Singleton retry semantics
On Fri, 2003-08-15 at 13:45, Barlow, Dustin wrote: In the invoker-proxy-binding configuration I still have the following stanzas under proxy-factory-config: MaximumSize15/MaximumSize MaxMessages1/MaxMessages I wasn't exactly sure what the MaximumSize was doing so I just left it at 15. So, if I switch MaximumSize to 1, this may give me the behaviour I'm looking for? It would make it better. I still am a bit fuzzy on the part where if the retry implementation is just simply pushing the message back onto the source queue, then there would be no way to guarantee that no other messages would be in front of that reposted message correct? Or am I misunderstanding the MDB retry implementation in JBossMQ? Let me do a little pseudo code: 1) ConnectionConsumer retrieves message1 2) ConnectionConsumer gets a session which enlists in the transaction 3) ConnectionConsumer asks for next message 4a) Session delivers message1 to the MDB 4b) ConnectionConsumer gets the next message2 and asks for Session (there are none available so wait) 5) MDB rollsback the transaction which nacks message1 back into the queue 6) ConnectionConsumer reuses the session for message2 7) ConnectionConsumer asks for next message it is message1 It is step 4b that causes your problem. NOTE: Other JMS implementations may not implement the ConnectionConsumer the same way. This is not defined in the spec. Regards, Adrian Dustin -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 6:58 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] MDB Singleton retry semantics So you're wait is really on the mdb pool not the session pool. The session pool wait is still there. You probably still have the default 15 sessions in the pool? Under load, this will mean you have 1 session delivering its message and 14 waiting for the single instance mdb. Each of those 14 sessions will have a message attached. Regards, Adrian On Thu, 2003-08-14 at 21:13, Barlow, Dustin wrote: In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container transaction rollback. BTW: I'm using JBoss 3.2.2RC2. Dustin -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 8/14/2003 2:27 PM Subject: RE: [JBoss-user] MDB Singleton retry semantics How are you enforcing the singleton? -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- 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/psa0013ave/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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
Setting the MaximumSize to 1 does indeed fix the problem, or at least masks it. Now, this begs the question of since there is a complete rewrite of JMS in the 4.0 series, and I am planning to upgrade from the 3.2 series to 4 series to utilize the new JBossDO implementation, will this same behaviour be in the 4.0 series as well? The second issue this brings up is transaction behaviour. I have a CMT MDB consuming on queue/A. The MDB fires and calls a CMT SSB that subsequently pushes a message onto queue/B (JMS access done via a ConnectionFactory gotten from java:/JmsXA). For sake of the example I have two messages sitting on the queue. The first message is going to write to queue/B, the second one is going to use a queue browser and lookup what the message on queue/B that the first message coming from queue/A wrote. The behaviour I've witnessed is that when message one succeeds and goes into the final commit stage of the CMT, message two actually fires prior to the container transaction fully committing message one's work to queue/B. This means that message two doesn't see the message on queue/B that message one wrote to it. I presume this behaviour is also due to the ConnectionConsumer read-ahead strategy? I was under the impression that if I have a singleton MDB, that the second message on the queue would not be fired until the first message is fully consumed, and any resources that message had altered would be fully committed prior to the next message on the queue being consumed by the MDB. It seems that the commit of the first message is happening async to the consumption of the second message. Setting the MaximumSize on the proxy-factory-config to 1 fixed/masked this scenario as well. I don't know what the spec has to say about the above scenario, but it seems to me that if I want true acidity of resources in the case of a singleton MDB setup, that the second message should not fire until message one had been consumed and all resources that enlisted in the container transaction should be actually commited so that message two could see them when it fires. Dustin -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 9:55 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] MDB Singleton retry semantics On Fri, 2003-08-15 at 13:45, Barlow, Dustin wrote: In the invoker-proxy-binding configuration I still have the following stanzas under proxy-factory-config: MaximumSize15/MaximumSize MaxMessages1/MaxMessages I wasn't exactly sure what the MaximumSize was doing so I just left it at 15. So, if I switch MaximumSize to 1, this may give me the behaviour I'm looking for? It would make it better. I still am a bit fuzzy on the part where if the retry implementation is just simply pushing the message back onto the source queue, then there would be no way to guarantee that no other messages would be in front of that reposted message correct? Or am I misunderstanding the MDB retry implementation in JBossMQ? Let me do a little pseudo code: 1) ConnectionConsumer retrieves message1 2) ConnectionConsumer gets a session which enlists in the transaction 3) ConnectionConsumer asks for next message 4a) Session delivers message1 to the MDB 4b) ConnectionConsumer gets the next message2 and asks for Session (there are none available so wait) 5) MDB rollsback the transaction which nacks message1 back into the queue 6) ConnectionConsumer reuses the session for message2 7) ConnectionConsumer asks for next message it is message1 It is step 4b that causes your problem. NOTE: Other JMS implementations may not implement the ConnectionConsumer the same way. This is not defined in the spec. Regards, Adrian Dustin -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 6:58 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] MDB Singleton retry semantics So you're wait is really on the mdb pool not the session pool. The session pool wait is still there. You probably still have the default 15 sessions in the pool? Under load, this will mean you have 1 session delivering its message and 14 waiting for the single instance mdb. Each of those 14 sessions will have a message attached. Regards, Adrian On Thu, 2003-08-14 at 21:13, Barlow, Dustin wrote: In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container
RE: [JBoss-user] MDB Singleton retry semantics
On Fri, 2003-08-15 at 16:38, Barlow, Dustin wrote: Setting the MaximumSize to 1 does indeed fix the problem, or at least masks it. Now, this begs the question of since there is a complete rewrite of JMS in the 4.0 series, and I am planning to upgrade from the 3.2 series to 4 series to utilize the new JBossDO implementation, will this same behaviour be in the 4.0 series as well? JBoss4 implements the integration using JCA1.5 MessageEndpoint The ConnectionConsumer is no longer used. You should consider JBoss4 alpha quality software. The second issue this brings up is transaction behaviour. I have a CMT MDB consuming on queue/A. The MDB fires and calls a CMT SSB that subsequently pushes a message onto queue/B (JMS access done via a ConnectionFactory gotten from java:/JmsXA). For sake of the example I have two messages sitting on the queue. The first message is going to write to queue/B, the second one is going to use a queue browser and lookup what the message on queue/B that the first message coming from queue/A wrote. The behaviour I've witnessed is that when message one succeeds and goes into the final commit stage of the CMT, message two actually fires prior to the container transaction fully committing message one's work to queue/B. This means that message two doesn't see the message on queue/B that message one wrote to it. I presume this behaviour is also due to the ConnectionConsumer read-ahead strategy? I was under the impression that if I have a singleton MDB, that the second message on the queue would not be fired until the first message is fully consumed, and any resources that message had altered would be fully committed prior to the next message on the queue being consumed by the MDB. It seems that the commit of the first message is happening async to the consumption of the second message. Setting the MaximumSize on the proxy-factory-config to 1 fixed/masked this scenario as well. I don't know what the spec has to say about the above scenario, but it seems to me that if I want true acidity of resources in the case of a singleton MDB setup, that the second message should not fire until message one had been consumed and all resources that enlisted in the container transaction should be actually commited so that message two could see them when it fires. First, QueueBrowsers are not transactional objects. I don't quite get what you are trying to achieve, if I understand it correctly, this isn't going to work (even ignoring my comment about the QueueBrowser). (A) tx1 processes message1 and commits a message to (B) (B) tx2 processes that message (A) tx3 tries to look at the message from the first step but it is already gone ACID has nothing to say about this - it is three different transactions. It is just a plain old race condition. Does tx2 or tx3 run first, who knows? You can search for previous discussions on XA commit semantics on this list. Regards, Adrian 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
JBoss4 implements the integration using JCA1.5 MessageEndpoint The ConnectionConsumer is no longer used. You should consider JBoss4 alpha quality software. And I do. However, that doesn't answer the question of retry behaviour for MDBs in 4.0. Basically will the implementation in 4.0 for singleton MDBs operate similiar to what we've already discussed here for the 3.2 series. First, QueueBrowsers are not transactional objects. I know and agree. I don't quite get what you are trying to achieve, if I understand it correctly, this isn't going to work (even ignoring my comment about the QueueBrowser). (A) tx1 processes message1 and commits a message to (B) (B) tx2 processes that message (A) tx3 tries to look at the message from the first step but it is already gone ACID has nothing to say about this - it is three different transactions. It is just a plain old race condition. Does tx2 or tx3 run first, who knows? You can search for previous discussions on XA commit semantics on this list. There is no MDB or MessageListener attached to the second queue (queue/B). I'm basically using the second JMS queue (queue/B) as a temporary object storage space. So the message posted to queue/B in the scenario I spelled out in my prior post would/should be on the queue when the second message from queue/A triggers. Apart of message2's business logic does a lookup (via a QueueBrowser) for the message that the message1 process posted on queue/B. Below is a simplified example. 1. Two messages sitting on queue/A 2. Singleton MDB attached to queue/A 3. Message1 triggers from queue/A 4. The MDB calls a CMT SSB that does some business logic one leg of which is a post of a new message to queue/B. 5. The stack returns back to the MDB successfully and the CMT commit process begins. 6. Message2 triggers from queue/A. 7. The MDB calls a different CMT SSB that looks up (using a QueueBrowser) on queue/B the data that message1 put on the queue. In the above scenario, the process triggered by message2 on queue/A doesn't always see the message posted on queue/B by message1's process. My observation is that in the case of a singleton MDB setup with a Session MaxSize greater then one, there seems to be a race condition since the Session used by message1 has now been freed allowing message2 to be triggered prior to the container actually finishing its work of committing all enlisted resources that message1's flow changed (including the post to queue/B). 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
On Fri, 2003-08-15 at 19:59, Barlow, Dustin wrote: JBoss4 implements the integration using JCA1.5 MessageEndpoint The ConnectionConsumer is no longer used. You should consider JBoss4 alpha quality software. And I do. However, that doesn't answer the question of retry behaviour for MDBs in 4.0. Basically will the implementation in 4.0 for singleton MDBs operate similiar to what we've already discussed here for the 3.2 series. Effectively yes. But the pooling is one the details that still needs to be looked at in jboss4. I don't believe the MDB strict pooling has been forward ported from 3.2? First, QueueBrowsers are not transactional objects. I know and agree. I don't quite get what you are trying to achieve, if I understand it correctly, this isn't going to work (even ignoring my comment about the QueueBrowser). (A) tx1 processes message1 and commits a message to (B) (B) tx2 processes that message (A) tx3 tries to look at the message from the first step but it is already gone ACID has nothing to say about this - it is three different transactions. It is just a plain old race condition. Does tx2 or tx3 run first, who knows? You can search for previous discussions on XA commit semantics on this list. There is no MDB or MessageListener attached to the second queue (queue/B). I'm basically using the second JMS queue (queue/B) as a temporary object storage space. So the message posted to queue/B in the scenario I spelled out in my prior post would/should be on the queue when the second message from queue/A triggers. Apart of message2's business logic does a lookup (via a QueueBrowser) for the message that the message1 process posted on queue/B. Below is a simplified example. 1. Two messages sitting on queue/A 2. Singleton MDB attached to queue/A 3. Message1 triggers from queue/A 4. The MDB calls a CMT SSB that does some business logic one leg of which is a post of a new message to queue/B. 5. The stack returns back to the MDB successfully and the CMT commit process begins. 6. Message2 triggers from queue/A. 7. The MDB calls a different CMT SSB that looks up (using a QueueBrowser) on queue/B the data that message1 put on the queue. In the above scenario, the process triggered by message2 on queue/A doesn't always see the message posted on queue/B by message1's process. My observation is that in the case of a singleton MDB setup with a Session MaxSize greater then one, there seems to be a race condition since the Session used by message1 has now been freed allowing message2 to be triggered prior to the container actually finishing its work of committing all enlisted resources that message1's flow changed (including the post to queue/B). That is correct, the MDB is returned to the pool (but the transaction has not yet committed). Another session waiting for the EJB can start its work while the previous one goes onto commit. Setting the ServerSessionPool to MaxSize 1 means that the single session has to commit before more can be done. The order of work is roughly: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) releaseMDB() 6) commitSession() With MaxSize 1 the wait and release are at 2 and 6 disallowing concurrency between two different transactions. With more than one session you gets waits at 3 and 5 with concurrent transactions. Of course, by default there is no wait at 3 because there is no strict pooling. Regards, Adrian 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
Adrian Brock wrote: The order of work is roughly: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) releaseMDB() 6) commitSession() Why couldn't the commitSession() be done prior to releaseMDB()? Seems that if 5 and 6 were flipped, the overall behaviour would be the same. Plus with a singleton MDB setup, one could take advantage of the read-ahead optimization by having MaxSize set to a value higher then one, and still have acidity of CMT between each MDB invocation of onMessage(). Otherwise, you basically have to choke off the pooling at the session level to keep the async behaviour of the MDB at bay until the session commits. Is it done that way because another transactable resource could be enlisted for which the session would have to commit after releaseMDB()? Even if the MDB itself calls a CMT SSB, the releaseMDB() would be presumably done after the releaseSSB(). IE: 1) receive() 2) getSession() and enlist in tx 3) getMDB() 4) onMessage() 5) invoke CMT method on SSB() 5) getSSB() and enlist in tx 6) run CMT method 7) releaseSSB() 8) releaseMDB() 9) commitSession() 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
How are you enforcing the singleton? -- Danny Yates -Original Message- From: Barlow, Dustin [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 19:00 To: [EMAIL PROTECTED] Subject: [JBoss-user] MDB Singleton retry semantics 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user _ Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority. _ --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
Hi, Please keep the mails on the list so that everybody can share the discussion. On Thu, 2003-08-14 at 21:30, Barlow, Dustin wrote: I guess it isn't obvious to me why is readahead important in terms of efficiency of queue message consumption. Can you elaborate? The readahead means the ConnectionConsumer can get the next message(s) while you process the current one(s). It only has to wait for a session to become available to process those messages. 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. It is not supported with the current implementation. It could be supported with the changes I mentioned to the ConnectionConsumer, but this wouldn't be portable to other JMS implementations and see below. 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? It wouldn't guarantee it, the message is put back at the top of the queue - but higher priority messages could have arrived in the mean time. This problem and the no guarantee of ordering for MDBs (because of the concurrent sessionpool) is mentioned in the spec. JBoss lets you avoid the concurrency problem but not the ordering problem of redelivery. The actual ordering is message priority then arrival order (the initial arrival not the nack). Regards, Adrian 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
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/psa0013ave/direct;at.aspnet_072303_01 /01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] MDB Singleton retry semantics
In conf/standardjboss.xml I setup a new invoker-proxy-binding and a container-configuration. Part of the container-configuration includes the following stanzas: container-pool-conf MaximumSize1/MaximumSize MinimumSize1/MinimumSize strictMaximumSizetrue/strictMaximumSize /container-pool-conf The MDB is deployed using the new invoker-proxy-binding and container-configuration and does only consume one message at a time as long as there isn't a container transaction rollback. BTW: I'm using JBoss 3.2.2RC2. Dustin -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 8/14/2003 2:27 PM Subject: RE: [JBoss-user] MDB Singleton retry semantics How are you enforcing the singleton? -- Danny Yates -Original Message- From: Barlow, Dustin [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 19:00 To: [EMAIL PROTECTED] Subject: [JBoss-user] MDB Singleton retry semantics 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/psa0013ave/direct;at.aspnet_072303_01 /01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user _ Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority. _ --- 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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
