I've been running some tests with an application on JBoss AS6 (and comparing performance to Glassfish 3.0.1) and seeing some puzzling behavior. This application runs a netty server, which makes use of an 8 thread Executor pool to do IO operations. The tasks running in this pool can call a Stateless EJB, which in turn makes a remote http call, etc.
In my test, I'm creating a client task that sends a request to this server and then upon receiving the response it will send any other requests to the server which I have placed in a client queue. Currently, I'm queuing 500 requests in a client. I'm also creating 9 tasks which execute the same type of test client concurrently, which I'm submitting to an Executor to process. So, if I run the test code once, the application processes a total of 4509 requests (500 + the initial request, starting the client/server communication).
I my logging, I'm keeping track of how many SLSBs are created (using a static AtomicInteger field in the bean class) by the application service. With glassfish, I'm seeing the server create 8 SLSBs when I run the test once. If I run more tests, one after the other, Glassfish reuses the 8 SLSBs that it initially created. However, with JBoss AS6, each time I execute the test, it creates 8 new SLSBs (in the 3rd or 4th iterations it appears to be 6 or 7 new ones sometimes). They are created immediately when the test is started, and then none are created when the test is processing. So, if I run this type of test 4 times, JBoss AS6 ends up creating > 30 SLSBs, while Glassfish only does 8.
So, in summary, it doesn't look like the EJB container is currently pooling SLSBs very efficiently. I encountered the problem before in another test which was using a SLSB as a JMS producer, and in my bean, I was creating the JMS connection on bean initialization and closing it when the bean was destroyed. Well, the default JCA setting for AS6 allows 20 connections. So, the container would create eventually create 21 beans, and throw an exception because the JMS connection couldn't be established.
I'm wondering if this is the intended behavior with the EJB container? If so, maybe it can be tuned somehow? I have concerns about external resource usage of some of my SLSBs with the current observed behavior (not to mention the JBoss AS6 server memory usage).