CODEWITHSUNDEEP
jakarta-eenumbersejbcapacity
Luis Soeiro
Luis Soeiro

Reputation: 4272

How many remote EJB clients can a single Java EE server handle?

We have a situation where there are around 450 remote EJB clients that need to connect to a Java EE server (OpenEJB 3.1.4 container). No HTTP server is present.

We've noticed that after a number of clients are brought on line, the server begins to throw javax.ejb.ConcurrentAccessTimeoutException.

The docs say that it is caused by a timeout while attempt to concurrently access a stateful session bean or a singleton bean in a method. We actually use both, but it is hard to figure out what a good value for a timeout might be.

If the value is high, we get less ConcurrentAccessTimeoutExceptions but lots of client just start to hang there forever. If the value is low, lots of ConcurrentAccessTimeoutExceptions are thrown.

All 450 clients establish a connection to the server on start up (because the connection time is too high to be made on demand) and maintain it forever.

Now, there is another problem, on top of that. Every client constantly polls the server at a 2 second interval. We can change this behaviour, but we will have to adjust the architecture.

Is there study or anyone who has had experience with many clients connecting to a Java EE server out there?

We can design for whatever is needed, but we would like to have a more specific target.

Upvotes: 0

Views: 496

Answers (1)

David Blevins
David Blevins

Reputation: 19368

Might be a tricky question to answer on StackOverflow as ultimately this is a threading issue that has nothing to do with EJB specifically. The question is more or less identical to "I have code that executes in a synchronized block, how many threads should I be able to use and keep things fast?"

The real question is what is the code in the synchronized block doing? (i.e. the @Stateful bean or @Lock(WRITE) method of the @Singleton). The goal being to eliminate the need for synchronization or at the very least shorten the duration that synchronized code runs.

There are concrete ways to get this information.

One technique would be to increase the timeouts to near infinity and then when things hang, issue a kill -3 12345 on the command line where 12345 is the process id of the server. That will cause a thread dump to be spit out onto the System.out of the server.

That output will show you exactly what every thread is doing and what method it us currently invoking and if that thread is in a waiting state. You'll want to pick through that output several times.

It should give you some leads as to what areas of the code might be holding up the show the most. The question to answer is what is the code doing that is causing other thread to have to wait.

Upvotes: 1

Related Questions