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.


2005/12/15, Dieter Maurer <[EMAIL PROTECTED]>:
> 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
Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to