[Zope] Zope 2.8.4 strange behavior

[Dennis Allison]

Chris, 

A helpful suggestion.   The commit errors I've been seeing have to 
do with the intereaction of the ZODB, MySQL, session variables, and 
conflicts.  

These particular problems do not appear to be related to the ZODB/session
variable/conflict issues, but I cannot completely exclude them since leaks
easily cause failures far away from where the fault lies.

It certainly is a worthwhile thing to check and monitor.

   -d




On Sun, 27 Nov 2005, Chris McDonough wrote:

> 
> On Nov 27, 2005, at 8:13 PM, Dennis Allison wrote:
> 
> > here to begin to track this one down.  The failure
> > is spontaneous and apparently not triggered by any readily  
> > distinguishable
> > inputs or pattern of inputs.  The behavior smells a bit of resource  
> > limits
> > or process synchronization problems, but there is not real evidence  
> > for
> > either being the root cause.   I am not sure what monitoring I  
> > should be
> > doing to help locate the source of the problem.
> >
> > Has anyone seen seen a similar problem?  Any advice as to how to  
> > proceed?
> 
> A pool of database connections is kept around to pull from for each  
> ZODB database you have.  By default, there are 7 of them per  
> database; this number can be changed by the pool-size parameter in  
> the <zodb_db> section in your config file.  These connections are  
> returned to the pool when a connection is closed.  This usually  
> happens when a transaction that is using that connection completes.
> 
> The symptom you're describing has happened to me in the past.  Zope  
> stops serving requests and my CPU is not pegged (it's not hitting the  
> CPU hard via an infinept loop I've made).  I usually end up tracking  
> it down to the fact that my instance is somehow leaking database  
> connections.  The connection is never closed so it never gets  
> returned to the pool.  This can happen when there is an error during  
> a transaction commit or abort.
> 
> Since you've previously posted to the list with commit errors of just  
> this kind, it seems like that would be the logical place to start.   
> You didn't mention seeing any of these errors, though, so if you  
> don't see any of those in the event log, I'm not sure where to go  
> from there other than debugging by binary exclusion which can be  
> impossible when the failures happen so far apart. :-(
> 
> - C
> 

--