On Tue, 2004-02-03 at 21:10, Barlow, Dustin wrote: > I am trying to understand how the StdJMSPool configuration is related to the > invoker-proxy-bindings and the subsequent container-configurations. > > For example, the defaultsetup is as follows: > > <invoker-proxy-binding> > <name>message-driven-bean</name> > <invoker-mbean>default</invoker-mbean> > > <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory> > <proxy-factory-config> > <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI> > > <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI> > <MaximumSize>15</MaximumSize> > <MaxMessages>1</MaxMessages> > <MDBConfig> > <ReconnectIntervalSec>10</ReconnectIntervalSec> > <DLQConfig> > <DestinationQueue>queue/DLQ</DestinationQueue> > <MaxTimesRedelivered>10</MaxTimesRedelivered> > <TimeToLive>0</TimeToLive> > </DLQConfig> > </MDBConfig> > </proxy-factory-config> > </invoker-proxy-binding> > > <container-configuration> > <container-name>Standard Message Driven Bean</container-name> > <call-logging>false</call-logging> > > <invoker-proxy-binding-name>message-driven-bean</invoker-proxy-binding-name> > <container-interceptors> > > <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</intercepto > r> > <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> > > <interceptor>org.jboss.ejb.plugins.RunAsSecurityInterceptor</interceptor> > <!-- CMT --> > <interceptor > transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor> > <interceptor transaction="Container" > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor> > <interceptor > transaction="Container">org.jboss.ejb.plugins.MessageDrivenInstanceIntercept > or</interceptor> > <!-- BMT --> > <interceptor > transaction="Bean">org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor</i > nterceptor> > <interceptor > transaction="Bean">org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT</inte > rceptor> > <interceptor transaction="Bean" > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor> > > <interceptor>org.jboss.resource.connectionmanager.CachedConnectionIntercepto > r</interceptor> > </container-interceptors> > > <instance-pool>org.jboss.ejb.plugins.MessageDrivenInstancePool</instance-poo > l> > <instance-cache></instance-cache> > <persistence-manager></persistence-manager> > <container-pool-conf> > <MaximumSize>100</MaximumSize> > </container-pool-conf> > </container-configuration> > > > If I setup another invoker-proxy-binding and then a new > container-configuration that uses that new invoker-proxy-binding, both of > which have different container-pool-conf sizes and max/min message sizes, is > this a problem if I also use the StdJMSPool for the > ServerSessionPoolFactoryJNDI?
It is just a factory for the pooling implementation. Nothing to see here, move along... > > I am seeing errors that say I've exhausted the session pools, which I assume > is the StdJMSPool. I upped the <MaximumSize> on the <container-pool-conf> > to be well above the actual number of MDBs firing, but to no avail. I saw > no way to increase the size of StdJMSPool in the jms-ds.xml file either, so > I'm not sure what to try next. I can't find any reference to "exhausted" or "exhaust" in either the session pool, the jms connection, the mdb pool or anywhere else in the mdb container. Care to provide a stacktrace? 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. The mdb pool in the container configuration is just a repository for currently unused mdb instances unless you enabled strict pooling. Regards, Adrian > > Is the proper thing to do is to setup a new version of the StdJMSPool > service for each new invoker-proxy-binding that is created, or is it ok to > recycle the same JMSPool? > > 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
