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: > > > > <MaximumSize>15</MaximumSize> > > <MaxMessages>1</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> > > > > <MaximumSize>1</MaximumSize> > > > > <MinimumSize>1</MinimumSize> > > > > <strictMaximumSize>true</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? > > > -- > > > 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 ------------------------------------------------------- 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
