[ZODB-Dev] Zope or Zeo hanging up sockets

[Matt]

I was wondering about thread locking problems and was going to look into
4Suite with that in mind.  I have turned on the -M logging and hope to see
the pattern repeat again in the next few days, but adding some logging of my
own in the methods is a good idea, thanks for the suggestion.  If it is the
locking problem, then presumably I could write a seperate method that sits
there trying to get a lock n times a second and then run these External
methods to see whether the count drops, i.e. failing locks on a large scale
?  I need to find some documentation/source to understand the significance
of these threading issues in Zope.

Should I be swapping this thread to the main zope list?  I worry things are
missing in the scroll now without the previous messages.

Matt


----- Original Message -----
From: "Toby Dickenson" <tdickenson@devmail.geminidataloggers.co.uk>
To: "Matt" <matt@virtualspectator.com>
Cc: "Chris McDonough" <chrism@zope.com>; <zodb-dev@zope.org>
Sent: Wednesday, November 28, 2001 10:47 PM
Subject: Re: [ZODB-Dev] Zope or Zeo hanging up sockets


> On Wed, 28 Nov 2001 16:44:21 +1300, "Matt" <matt@virtualspectator.com>
> wrote:
>
> >First of all, and don't laugh, the following are the external methods
> >involved :
>
> There may be an obvious soution... Does that external method use any
> extension modules that might not be giving up the python global lock,
> or any python modules that are using thread synchronisation?
>
> (my appologies if that question is *too* obvious)
>
> >dom document of the 4Suite kind
>
> I remember one of Python's xml libraries relies on the python garbage
> colelctor to break circular references. Is that 4Suite, or another
> one? The blockage may be due to the garbage collector, although 40s is
> much slower that I have ever seen it before.
>
>
> >>>A sockstat shows that
> >> connections
> >> > are piling up to Zope.  I watched the logs for a while and found
> >> that when a
> >> > certain external method was called that takes up to 10 seconds to
> >> run and
> >> > return, that all the other requests pile up behind it.  When it
> >> finally goes
> >> > through then a burst of some, but not all, of other pending requests
> >> goes
> >> > through
>
> You could modify your external method to write a log file with
> timestamps on entry, exit, and at any landmarks within the external
> method. That may help isolate exactly what is blocking.
>
>
>
> Toby Dickenson
> tdickenson@geminidataloggers.com