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.
You could try XMLRPCMethod.
It creates its own worker thread and has a configurable timeout.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -