Thanks, I will definitely look into that for my immediate problems. Ole 2005/12/16, Michael Haubenwallner <michael@d2m.at>:
Jan-Ole Esleben wrote:
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
You could try XMLRPCMethod. It creates its own worker thread and has a configurable timeout.
Michael
[1] http://www.zope.org/Members/EIONET/XMLRPC
-- http://zope.org/Members/d2m http://planetzope.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )