Thanks; this is a problem we are well aware of. Our solution is to increase the amount of workers, obviously. However, I'm increasingly getting a feeling that for a rather big range of unlikely situations that are nonetheless to be expected, Zope doesn't work _at all_. In a WebServices setting, situations like the one I described, with one server calling back to another server within a call from that latter server and both not knowing anything about the implementation of the other, it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them for persistent objects that actually _do_ change state (unlike mine). The solution is to not have state in your objects, and thus lose instantly most of what Zope is. However, as I see it, the problem is that what Zope actually _is_ (i.e. mostly the ZODB) is an unhealthy way of coupling data and implementation (which is _exactly_ why my implementation didn't work immediately). This of course comes from its origins in TTW development where there wouldn't actually have been many user made products. Please tell me if I'm wrong with my assumption above, and why. I'm not trying to be inflamatory, this just has me really worried. Ole 2005/12/15, Dieter Maurer <dieter@handshake.de>:
Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:
Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?
In principle yes.
Be careful however: it is easy to introduce deadlocks!
When during request processing you call back into the same Zope via XML-RPC, the calling out request will not complete until the XML-RPC returns a result (this always holds for calls, XML-RPC or other, to an external or internal server).
Zope has a limited amount of workers (the default is 4) able to execute requests. If there are no free workers, requests have to wait for one.
Now imagine that as many requests arrive as there are workers and each of them wants to perform an XML-RPC against the same Zope. Then you have a deadlock: none of the XML-RPC requests will finish, because there are no free workers. An no worker will ever become free again, because each of them waits for its XML-RPC to finish.
Therefore, you should directly call internal resources (rather than use XML-RPC).
-- Dieter