Concurrent XML-RPC?

Jordan Krushen jkrushen at data-fortress.com
Sun Feb 24 23:42:06 EST 2002


I know this has been asked before (or something close), but having explored
as much as I can, I still haven't found an existing, lightweight way to have
true concurrency when serving XML-RPC.  While Medusa is ok for IO-bound
stuff, we'll be doing some heavy db-driven processing, which when run under
Medusa is serialized.  Obviously, the SocketServer code behaves this way, as
well.

Is there a patch for the SocketServer code anywhere to allow it to run under
inetd?  I'd hate to have to rewrite all the xmlrpclib handling of the
connections, and this would allow me to run it under DJB's tcpserver,
obviously giving us the concurrency we need.

I've also heard that Zope's ZServer might do the trick, is this simple
enough?  (Note the above mentioning of 'lightweight' :)

What we're wanting is a framework where one can simply take the appropriate
library and use an automated installer, which would talk to a centralized
authority telling it which IP/port to bind to, set up all the
stunnel/tcpserver instances, generate certificates, etc.  I imagine
somewhere around 50 separate, independent XML-RPC services would exist at a
time, talking between themselves and the outside world.  Of course, many of
these instances may be running on the same host, so we'd like them to be as
lightweight as possible.

Any thoughts?

J.





More information about the Python-list mailing list