ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wilson <...@wilson.co.uk>
Subject Re: Non-blocking container for xmlrpc
Date Tue, 20 Sep 2005 17:00:18 GMT

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



Mime
View raw message