On 20 Sep 2005, at 17:38, Dan Hermann wrote:
Thank you for the reply. The "Thread per request" paragraph in the
URL
above describes what I think I'll need for my application.
I think jetty 6 will do what you want but there may be a simpler
solution - see below
If you give us a little more information we may be able ot offer
some more suggestions.
Just to clarify, I'm building an xmlrpc server application that must
handle bursts of separate requests (up to 10,000 or so) from clients.
With a thread per connection model, that many requests kills the
server.
I'll then delegate handling of those requests to a much smaller
pool of
request handlers. Strictly speaking, this isn't a problem with
xmlrpc.
It's just that with xmlrpc's built-in webserver, the
thread-per-connection limitation is very apparent. As you point
out, I
think I can embed xmlrpc inside Jetty to eliminate that problem. The
only additional consideration I can think of is the XmlRpcServer
class's
limitation on the number of worker threads. I'll have to throttle
back
the processing of requests so as to not exceed that limitation.
If you can set the backlog on the ServerSocket to 10,000 then the
existing code should handle your scenario. You should set the maximum
number of worker threads to optimum value for your hardware
configuration (that's a matter of experimentation and depends on what
the calls are doing).
The high backlog value will ensure that connections are still
accepted when all the worker threads are busy and the requests will
be satisfied as and when threads come free.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
