[Zope] Zope 2.8.4 strange behavior

[Tim Peters]

[Chris McDonough]
>> 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.

[Chris Withers]
> I thought Jim solved this for 2.8 by not having a hard limit on the
> connection pool?

This was implemented for ZODB 3.4.  See:

    http://www.zope.org/Wikis/ZODB/SimplifyConnectionManagement

and ZODB NEWS.

> (iirc, you now get errors in the log when you go over the pool limit)

Messages at warning or critical level, depening on how much you've gone over.

> This was 'cos you used to get the crappy situation running unit tests when
> lots of test fail that things hang and you get no feedback apart from 7 E's
> because the connection pool is exhausted.

Not really (see the Wiki page referenced above).

> That said, I don't know for sure that Jim _did_ end up implementing
> this, I might just be imagine it.

It was released in ZODB 3.4a1:

"""
What's new in ZODB3 3.4a1?
==========================
Release date: 01-Apr-2005

...

DB
--

- There is no longer a hard limit on the number of connections that
  ``DB.open()`` will create.  In other words, ``DB.open()`` never blocks
  anymore waiting for an earlier connection to close, and ``DB.open()``
  always returns a connection now (while it wasn't documented, it was
  possible for ``DB.open()`` to return ``None`` before).

  ``pool_size`` continues to default to 7, but its meaning has changed:
  if more than ``pool_size`` connections are obtained from ``DB.open()``
  and not closed, a warning is logged; if more than twice ``pool_size``, a
  critical problem is logged.  ``pool_size`` should be set to the maximum
  number of connections from the ``DB`` instance you expect to have open
  simultaneously.

  In addition, if a connection obtained from ``DB.open()`` becomes
  unreachable without having been explicitly closed, when Python's garbage
  collection reclaims that connection it no longer counts against the
  ``pool_size`` thresholds for logging messages.

  The following optional arguments to ``DB.open()`` are deprecated:
  ``transaction``, ``waitflag``, ``force`` and ``temporary``.  If one
  is specified, its value is ignored, and ``DeprecationWarning`` is
  raised.  In ZODB 3.6, these optional arguments will be removed.
"""

And for ZODB 3.6, they were removed.