Tim Peters wrote:
[Dieter Maurer]
They did not tell us about their application. But, Zope's database
adapters work like this. They use the ZODB cache (and its pool) as an RDB
connection pool. Thus, if the ZODB caches are not released, the RDB
connections won't.
I believe you, but I'm not
Tim Peters wrote at 2006-1-2 15:05 -0500:
I'm still baffled by how you get into this state to begin with. Florent
explained why earlier, and I didn't see a reply to this part:
[Florent Guillaume]
By itself Zope never uses more than one connection per thread, and the
number of thread is
I'm still baffled by how you get into this state to begin with. Florent
explained why earlier, and I didn't see a reply to this part:
[Florent Guillaume]
Huh are you sure? That would mean you have thousands of threads. Or
hundreds or ZEO clients. Or hundreds of ZODB mountpoints.
By itself
FYI, I added code to clear the cache in _ConnectionPool at the time a closed
Connection is forgotten. This will be in ZODB 3.6 final, which in turn will
be in Zopes 2.9 and 3.2 final.
I don't have time for more here now, so if others want more it's up to them
;-)
...
P.S. Call me Pitcher, i
...
[Tim]
FYI, I added code to clear the cache in _ConnectionPool at the time a
closed Connection is forgotten. This will be in ZODB 3.6 final, which
in turn will be in Zopes 2.9 and 3.2 final.
[Pitcher]
Okay. Tank you. But it's good not always... You never said anything good
or bad of the
David Rushby wrote at 2005-12-30 11:14 -0800:
...
Since ZODB doesn't know whether the connection it's releasing from the
pool is still in use, I don't know whether resetting the connection's
cache is appropriate as a general solution. But it fixes a definite
problem with Zope's behavior as a
Tim Peters wrote at 2005-12-30 14:51 -0500:
[Dieter Maurer]
They did not tell us about their application. But, Zope's database
adapters work like this. They use the ZODB cache (and its pool) as an RDB
connection pool. Thus, if the ZODB caches are not released, the RDB
connections won't.
I
Tim Peters wrote at 2005-12-29 12:59 -0500:
...
[Tim Peters]
It means that _ConnectionPool no longer has a reason to remember
anything about that Connection. Application code can continue
keeping it alive forever, though.
[Denis Markov]
But what about RDB-Connection what stay in cache
[Dieter Maurer]
They did not tell us about their application. But, Zope's database
adapters work like this. They use the ZODB cache (and its pool) as an RDB
connection pool. Thus, if the ZODB caches are not released, the RDB
connections won't.
I believe you, but I'm not sure what to make of
[Tim Peters]
...
I suggested before that forcing calls to gc.collect() would give more
evidence. If that doesn't help, then it's most likely that the
application is keeping Connections alive.
[David Rushby]
I'm not the OP, but I was able to reproduce the problem he was
encountering. Calls
В Чтв, 29/12/2005 в 11:30 +0100, Florent Guillaume пишет:
A little bit of history...
We have zope as an application server for heavy loaded tech process. We
have high peaks of load several times a day and my question is about how
can we can avoid unused connections to remain in memory
[Florent Guillaume]
...
The self.all.remove(c) in _ConnectionPool attempts to destroy the
connection.
Nope, it's simply getting rid of a weak reference that no longer serves a
purpose, to avoid unbounded growth of the .all set in case of ill-behaved
application code, and to speed Python's
...
[Florent Guillaume]
The self.all.remove(c) in _ConnectionPool attempts to destroy the
connection. If something else has a reference to it once it's closed,
then that's a bug, and it shouldn't. It should only keep a weak
reference to it at most.
[EMAIL PROTECTED]
But it's nonsense!
Oops! I sent this to zope-dev instead of zodb-dev by mistake.
[EMAIL PROTECTED]
Not agree. Can you answer the question? Does self.all.remove(c) mean
that we WANT to destroy connection instance?
[Tim Peters]
It means that _ConnectionPool no longer has a reason to remember
anything about that
Tim Peters wrote at 2005-12-29 11:28 -0500:
...
Or there are no strong reference to `obj`, but `obj` is part of cyclic
garbage so _continues to exist_ until a round of Python's cyclic garbage
collection runs.
And this is *VERY* likely as any persistent object in the cache
has a (strong, I
[Tim]
...
Or there are no strong reference to `obj`, but `obj` is part of cyclic
garbage so _continues to exist_ until a round of Python's cyclic garbage
collection runs.
[Dieter Maurer]
And this is *VERY* likely as any persistent object in the cache has a
(strong, I believe) reference to
16 matches
Mail list logo
