Concurrent XML-RPC?
Jordan Krushen
jkrushen at data-fortress.com
Sun Feb 24 23:42:06 EST 2002
More information about the Python-list mailing list
Sun Feb 24 23:42:06 EST 2002
- Previous message (by thread): Correction: Re: string substitutions
- Next message (by thread): Concurrent XML-RPC?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): Correction: Re: string substitutions
- Next message (by thread): Concurrent XML-RPC?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list