Concurrent XML-RPC?

Geoffrey Talvola gtalvola at
Mon Feb 25 11:24:28 EST 2002

Jordan Krushen write:
> 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?

Webware's WebKit application server supports XML-RPC and is multi-threaded,
so it gives you the concurrency you need.  The only problem is that it
doesn't currently support the HTTP protocol directly, but instead requires
you to run it behind Apache, which probably disqualifies it as
"lightweight".  (There are at least 3 different experimental HTTP servers
for Webware which you are welcome to try but none are part of the Webware
core -- yet.)

- Geoff

More information about the Python-list mailing list