Questions about stateless session bean life cycle from clien

[mossprescott]

I have a bunch of stateless session beans running in JBoss 4.0.1sp1 which are being called by a Swing client via RMI. I would like the application to scale to hundreds of clients, and I'm beginning to look at performance tuning. So far, the results are encouraging; I've used Grinder 3 (incidentally a great tool: http://grinder.sourceforge.net) to simulate as many as 500 clients and things seem to hum along nicely. But I noticed a couple of things along the way.

When load is heavy, a significant amount of time is spent in the home.create() methods of the session beans. It turns out this is because I am calling create() before each individual call to each bean. This certainly doesn't seem right, but I am afraid to change it because I don't understand the behavior of the remote proxy with concurrency. Furthermore, changing this behavior in testing doesn't seem to reduce the load on the server in a detectable way. So, my questions:

1) What is the exact overhead of create() from a remote client? Is it always a socket connection? Is there any persistent cost to the server in terms of objects on the heap to manage the connection?

2) Is it safe to make multiple calls through the same proxy on multiple threads? Do I have to think about managing pools of them to save on create() calls, or can I just get one and use it freely?

3) More open-ended: what is the right pattern for implementing a multi-threaded client against stateless session beans? I'd like to comply with the anticipated EJB programming model, if only I could figure out what it is!

I hope someone finds this sort of thing interesting enough to comment.

Thanks,

- moss

[raist_majere]

I don't know if that's the problem you have, but by default JBoss is configured with a Pool of 100 beans per type. So when you have 500 clients accessing all the time, it has to create the 400 left.
You can configure this in jboss.home/server/default/conf/standardjboss.xml.

 <container-configuration>
 <container-name>Standard Stateless SessionBean</container-name>
 <call-logging>false</call-logging>
 <invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
 <container-interceptors>
 <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
 <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
 <!-- CMT -->
 <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
 <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
 <interceptor transaction="Container">org.jboss.webservice.server.ServiceEndpointInterceptor</interceptor>
 <interceptor transaction="Container">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
 <!-- BMT -->
 <interceptor transaction="Bean">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
 <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
 <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
 <interceptor transaction="Bean">org.jboss.webservice.server.ServiceEndpointInterceptor</interceptor>
 <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
 </container-interceptors>
 <instance-pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool>
 <instance-cache></instance-cache>
 <persistence-manager></persistence-manager>
 <container-pool-conf>
 <MaximumSize>100</MaximumSize>
 </container-pool-conf>
 </container-configuration>

See the "MaximumSize" tag?
Hope it helps.

[tterm]

Hello

2) Is it safe to make multiple calls through the same proxy on multiple threads? Do I have to think about managing pools of them to save on create() calls, or can I just get one and use it freely?


This is from the ejb specification and should answer this question:

"The container must ensure that only one thread can be executing an instance at any time. If a client
request arrives for an instance while the instance is executing another request, the container may throw
the java.rmi.RemoteException to the second request if the client is a remote client, or the
javax.ejb.EJBException if the client is a local client.[6]
Note that a session object is intended to support only a single client. Therefore, it would be an
application error if two clients attempted to invoke the same session object.
One implication of this rule is that an application cannot make loopback calls to a session bean instance."

If you have multiple threads for one proxy, than you would try to use the same bean instance. That's how I would understand this!

Thomas

[starksm64]

That description only applies to stateful beans. stateless beans have no such restriction.

[tterm]

Hello Scott,

I tested it and you are right. You can share the same proxy for multiple threads but each thread will get a separate instance from the pool of stateless beans. That means one session bean instance will never be shared for multiple threads on the same time, whether if you use the same proxy or not. Is this right?

Thomas

[mossprescott]

Thanks to everyone who replied. What Raist and Scott said agrees with what I understand from reading the spec. In a few words, there is no _server_side_ resource created to service any particular client. This means that in theory it isn't necessary to create() a new proxy for each client thread. So far so good.

What is _not_ spelled out in the spec is the behavior of the actual remote proxy on the client side. Specifically, are the client-side proxy classes thread safe with respect to calls to a stateless session bean? Can multiple threads invoke the remote methods concurrently?

My experiments with JBoss 4.0.1 show no problems caused by making multiple calls to the same proxy instance on different threads. Also, when loads are high, experiments show that extra create() calls add significant latency. So as far as I can determine this is an optimization I should be making.

But I'd prefer not to go that route if it means being dependent on some idiosyncracy of JBoss's implementation, so I'm still looking for some authoritative information.

Scott?

Thanks again,

-moss