We are trying to build a highly scalable server that communicates to the external world via XML-RPC. Since our system is going to be handling very high load (lots of concurrent requests and each request could require considerable amount of time to process) we want to optimize the number of threads in the system.
We decided to use WebServer class as the server container for our system rather than a servlet container as we wanted to have the lightest possible container. Since we could not find adequate documentation on the thread management of WebServer, we looked into the source.
It seems that Webserver has a pool of threads that it uses to process each request. Additionally, it has one instance of XmlRpcServer that it delegates the processing of the request to. XmlRpcServer it self has a pool of threads of its own, and it uses a thread from that pool to process the delegated request. So for each request we end up using 2 threads – one from the WebServer pool and the other from the XmlRpcServer pool, even though optimally we can do it in one thread per request.
Is our understanding of the thread management correct? If so then is there a way we can process a request in just one request?
Given the scalability challenge in our server, we also want to have control on the thread management of the system and don't want to rely on the default behavior provided by WebServer. So we are planning on doing the following:
- Create an XmlRpcServer object
- Call setMaxThreads on this object to control the size of the pool.
- Create a WebServer object with the create XmlRpcServer object.
Is this the right way to do? Will this also control the size of the WebServer threadpool?
Additionally, we would like to have a better control on the thread pool policies, rather than the stack based thread pool provided in the WebServer and XmlRpcServer. We would like to use some other kind of Executor provided in the java.util.concurrent package. How can we do that? If we do it in our code then we end up creating 3 threads per request, which will not be good for scalability?
We are beginning to suspect if our choice of going for XmlRpcServer was a good one. Our systems scalability requirements are challenging but it requires a very simple interface with the external world and hence we were attracted towards XmlRpc.
