WebServer handler threads

[Alex Young <al...@starcomm.co.uk>]

Hi, does anyone know if there is a way to make the server side handlers
multi-threaded. By default when you  try to access a particular method on
the server, that method is always run from the same object creating a
potential bottleneck. I realise the Connection objects spawned by the
WebServer run in their own thread but I dont see how this will avoid the
Handler bottleneck.

Can anyone throw some light on this?

Thanks

Alex Young

Re: WebServer handler threads

[Andrew Evers <an...@redwood.com>]

> Hi, does anyone know if there is a way to make the server side handlers
> multi-threaded. By default when you  try to access a particular method on
> the server, that method is always run from the same object creating a
> potential bottleneck. I realise the Connection objects spawned by the
> WebServer run in their own thread but I dont see how this will avoid the
> Handler bottleneck.

The server side handler objects are multi-threaded. We dispatch requests
from
multiple threads to the same handler object. The potential bottleneck is
within
the handler itself. If your code can handle multiple threads well, then
there is
no bottleneck. If you synchronize on a method that may be invoked from
multiple threads, then you have a bottleneck.

We have a 1-1 mapping between handler names and handler objects because
this is the safest way to handle potential state in the handler objects.

If you want to remove a potential bottleneck in your handler code, you can
write something along the lines of the worker management that we have in the
XmlRpcServer (which would otherwise suffer from exactly the same problem).
If you don't need state between invocations, then this is quite simple.

If you need per-connection state between invocations, you would need to
modify the framework (we would consider including any patches you could
provide).

The simplest way would be to create a class YourXmlRpcContext that
extends DefaultXmlRpcContext and adds a <type> getConnectionId()
method. Give it a constructor (String user, String password,
XmlRpcHandlerMapping mapping, <type> connectionId) that calls
super(user, password, mapping) and stores the connection id for later
retrieval.

Next, make your handler implement ContextXmlRpcHandler. This could maintain
a pool of worker objects. Since you implement ContextXmlRpcHandler, you have
access
to per-request context information so that you can dispatch requests from
the same
connection to the same handler. You will need to cast the XmlRpcContext back
to
YourXmlRpcContext. You may also need to use the Invoker to handle reflection
for
you.

Finally, you would also need to modify the Connection class in
WebServer.java to
create a connection id (eg. using the (local port, remote port, remote
server) triple
and call xmlrpc.execute(sin, new YourXmlRpcContext(username, password,
xmlrpc.getHandlerMapping(), connectionId));

Andrew.

RE: WebServer handler threads

[Danny Angus <da...@apache.org>]

> -----Original Message-----
> From: Alex Young [mailto:alex@starcomm.co.uk]
> Sent: 31 March 2003 13:11
> To: xml-rpc-cvs@apache.org
> Subject: WebServer handler threads
> 
> 
> Hi, does anyone know if there is a way to make the server side handlers
> multi-threaded. By default when you  try to access a particular method on
> the server, that method is always run from the same object creating a
> potential bottleneck. I realise the Connection objects spawned by the
> WebServer run in their own thread but I dont see how this will avoid the
> Handler bottleneck.
> 
> Can anyone throw some light on this?


I'm not sure about the http server in xmlrpc but in theory, and unless the handler methods ae synchronised, more than one connection handler thread can simultaneously call methods in your single handler object, or the static code in a Class. 

This is pretty much the reason "synchronised" exists, the default behaviour is the threaded behaviour _you_ want, if you want to restrict calls to a method so that they are only made one at a time then you have to synchronise the sensitive parts.

The "best" (in that it obeys the principle of least surprise) solution is to ensure that wherever possible your methods are "thread-safe", often this distills down to simply being sensible about the scope of variables, and assume that your methods may be called by more than one thread at a time. 
Save synchronisation for times where you may be reading or writing the state of objects which have state, I assume your handlers don't.

d.