Question

This is a more detailed version of the same question asked yesterday.

I have a client app which communicates with the server app through RMI calls to stateless EJBs. The initial context is being built with these config params:

InitialContext ctx = new InitialContext(new Hashtable<String, String>() {
  {
    this.put("java.naming.provider.url", "serverUrl:portNumber");
    this.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
    this.put("java.naming.factory.url", "org.jnp.interfaces.TimedSocketFactory");
  }
});

A proxy is then looked up using:

ServerBean bean = (ServerBean) ctx.lookup("ejb/ServerBeanImpl");

Client then spawns many threads sharing this same instance of the ServerBean. Every thread now and then invokes remote calls on the shared bean.

My question is, are these calls performed in a serial or parallel manner? Every remote call is executed on the server. Some computing is performed and a result is returned. If all calls are serialized then I’ll have to limit the number of existing threads since many of them can be blocked on the ServerBean.

Answer 1

The calls will be blocked by the container on the server side at the very least. But beware that nearly all app servers have thread pools to limit the number of requests, so having a stateless bean pool size of 1000 and a server thread pool size of 100 does you little good — your stateless bean pool will never grow past 100.

So the things to check are:

1. Is there a client-side connection pool and what is its size?
2. Is there a server-side thread pool and what is its size?

If there is no client-side connection pool and all threads share the same connection, you’re pretty much limited right there unless NIO is used between client/server.

If the goal is to just do things in parallel, I’d use the EJB 3.1 @Asynchronous method support which does support @Remote calls. That will give you the most concurrency the most portably without having to worry about throttling your own usage.