At 10:50 AM 3/6/99 -0500, Skip Montanaro wrote:

Glad to see this list has been created.

I am currently using ZopeHTTPServer in the following architecture:

Apache <-----> ZopeHTTPServer <-----> Musi-Cal DB HTTP XML-RPC

Some requests from the net (searches) require a full round-trip to the database. Other things, like displaying an otherwise static DTML page, don't. The problem is that the ZopeHTTPServer is single-threaded at the moment, so if a search takes a long time (say, a couple seconds), simple stuff like calling a DTML template (which might execute in a tenth of a second), block.

Actually you can run ZopeHTTPServer in multi-threaded mode. See the docs in the doc string. Basically you just use the -t switch. It's not a very smart threaded server, for example, it has no thread pool. But it works, assuming you're publishing a module which is safe for concurrent access by multiple threads.

This, of course, causes Apache to get its britches in a twist and lots of its child processes start to pile up, memory gets short, yadda, yadda, yadda. I've had some trouble with deadlocks when trying to run ZHS multi-threaded (probably missed some object that needed to be locked).

Hmm. So you did use it in multi-threaded mode? As I am sure you know, concurrency is not a trivial issue. Getting all the locking right can be hard.

Will running ZServer with its asyncore/asynchat modules help alleviate this problem?

Yes and no. If you won't/can't make you module safe for concurrent access, no server will be able to publish it faster than one request at a time. However, ZServer has an interesting architecture where by input and output are handled separately than publishing. Effectively, I/O is multi-threaded (thanks to asyncore/asynchat), while module publishing is multi-threaded using a thread pool (out of the box the size of the thread pool is 1). So, even if you decide not to publish your module concurrently ZServer will probably give you a little win over ZopeHTTPServer in single-threaded mode.

Will I need to make changes to Fredrik Lundh's XML-RPC code to make this work?

I don't know much about this code, but I doubt it is causing any concurrency issues or otherwise for you.

(XML-RPC is a given at this point. We're calling Musi-Cal's database from both Python and Perl at this point and it works great.)

Cool!

How stable is the ZServer alpha release?

It's OK. I personally wouldn't use it for production purposes at this time. There are lots of changes that Jim and I have talked about that will make it better. As soon as I get some time I'll put together another release and then we'll be into beta territory. But this is still probably a couple weeks out, considering all the other stuff I'm working on.

If it's mostly the FTP and PCGI support that is still experimental, I can live with that since I don't use either one.

These are definitely rougher than HTTP, though there are still some issues with HTTP (you might want to turn off chunking), and I'm not satisfied that error handling and logging are all working perfectly. Good luck. -Amos