On Wed, 2004-02-04 at 20:02, Barlow, Dustin wrote: > Adrian Brock wrote: > > The key contraint is the <MaximumSize> in the proxy config. This > > configures a pool of jms sessions that deliver messages to the mdb > > container. Once these are all used, no messages will be delivered > > until an mdb finishes its invocation/transaction. > > One other thing I forgot to mention in my last post is that <MaximumSize> on > the proxy-invoker doesn't appear to be the only thing that constrains > invocations of MDBs. A while back, you and I had a discussion here about > doing a singleton MDB. Setting the MaxSize and MaxMessages to 1 in the > proxy-binding wasn't enough to ensure that only one MDB fires at time and > that the next message on the queue only fires when the prior fully commits > it's work. > > The behaviour actually was that if the container-configuration wasn't set > the pool size to 1, then a MDB would fire even though the prior MDB had not > fully committed the transaction yet. This had to do with the read-ahead > optimization done by the container and could basically be choked off by > setting the container-configuration pools to 1 as well. >
I remember the discussion, but I don't remember that conclusion. The MDB instance is returned to the pool after onMessage() completes, which is before the jms session is made available to the next message. I don't see how it would have an affect? jms -> session pooling -> session -> invoker -> mdb pooling -> mdb We were discussing why limiting the mdb pool didn't work. > So I'm wondering read-ahead optimization is why 100 is the default size > container-config pool instead of mirroring the 15 max setting of the > proxy-invoker. > That is probably just historical. The MDB container config is very similar to stateless session beans and was probably copied from it. Typically only 15 mdb instances will be used. I say typically because you can attach multiple invoker-proxy-bindings to a container and deliver messages from multiple jms destinations. Regards, Adrian > Dustin > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > 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 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
