Zope leaking memory?
Pound-current (V 1.7+) Zope 2.6.4 Python 2.3.4 RH 7.3 Dual Athalon processors Occasionally, I see Zope gathering very large amounts of real memory. Normally buffering and the like seems to stabalize at around 500MB on a 4GB memory dual processor machine, but occasionally grows to 2.5GB or more. At the same time, CPU usage tends to fully occupy one of the processors for the threads holding all the memory. Clearly there is a problem. Any hints as to where to track down the problem?
I've noticed what I believe are "request leaks" if any variety of CMF is involved in a request though I haven't tracked this down. The symptoms are that every request causes the HTTPRequest class to have its reference count increased by one, plus a bunch of other objects are leaked because the request that was leaked apparently continues to hold on to references to them. This may or may not be what you are seeing. If you want to track something like this down, there is really no shortcut. My strategy (which I've never successfully used to actually fix a leak, mind you! ;-) is this: - Confirm that bare Zope doesn't leak by testing refcounts before and after you load the quickstart page several times (remember to clear the ZODB cache before you start hitting the site whenever trying to test refcounts). Look at the number of references to all classes in the Debug tab. These references should not normally grow on every request. - Do same for one of your "domain" objects. If you see leakage when trying this against a method of one of your domain objects, a binary-exclusion method is usually the only way to pin down the leak. Prevent half of the code that gets run when your domain object method is called from running. If you still see the leak, the leak happens in the code you didn't prevent from running. If you did, the leak happens in the code that ran. And so forth. It's tedious and time-consuming, which is probably why I've never successfully used it to fix a leak. ;-) - C On Sun, 2004-09-12 at 01:33, Dennis Allison wrote:
Pound-current (V 1.7+) Zope 2.6.4 Python 2.3.4 RH 7.3 Dual Athalon processors
Occasionally, I see Zope gathering very large amounts of real memory. Normally buffering and the like seems to stabalize at around 500MB on a 4GB memory dual processor machine, but occasionally grows to 2.5GB or more. At the same time, CPU usage tends to fully occupy one of the processors for the threads holding all the memory. Clearly there is a problem. Any hints as to where to track down the problem?
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris -- Thanks for the assist. I think that I found the source of the problem last night and the the memory leak hypothesis was a cockpit error. The problem manifested itself when running a find script which was doing an edit cleanup of a lot of stuff (thousands of ZUBBB discussions and ZUBB postings). One of the things the script did was to reset all the ZUBB methods to the default by copying in the half-dozen or so methods present in every instance of the discussions. Zope apparently treats the whole edit as a single transaction and buffers up the changes until it comes time to commit. Rewriting the edit script to do things a bit differently and only make changes when they are needed dropped the memory growth and time by a factor of eight or so. While not really anything I'd want to run execpt for the nonce to maintain the system, it did solve my immediate problem. The huge memory that got allocated did get released upon successful completion of the script (and when the script was aborted as well). Is there some mechanism to force a ZODB commit explicitly? If there were, then the edit script would have the structure: find the thing to edit edit the thing commit the edits and the resouce demands would be under control. On Sun, 12 Sep 2004, Chris McDonough wrote:
I've noticed what I believe are "request leaks" if any variety of CMF is involved in a request though I haven't tracked this down. The symptoms are that every request causes the HTTPRequest class to have its reference count increased by one, plus a bunch of other objects are leaked because the request that was leaked apparently continues to hold on to references to them.
This may or may not be what you are seeing.
If you want to track something like this down, there is really no shortcut. My strategy (which I've never successfully used to actually fix a leak, mind you! ;-) is this:
- Confirm that bare Zope doesn't leak by testing refcounts before and after you load the quickstart page several times (remember to clear the ZODB cache before you start hitting the site whenever trying to test refcounts). Look at the number of references to all classes in the Debug tab. These references should not normally grow on every request.
- Do same for one of your "domain" objects.
If you see leakage when trying this against a method of one of your domain objects, a binary-exclusion method is usually the only way to pin down the leak. Prevent half of the code that gets run when your domain object method is called from running. If you still see the leak, the leak happens in the code you didn't prevent from running. If you did, the leak happens in the code that ran. And so forth. It's tedious and time-consuming, which is probably why I've never successfully used it to fix a leak. ;-)
- C
On Sun, 2004-09-12 at 01:33, Dennis Allison wrote:
Pound-current (V 1.7+) Zope 2.6.4 Python 2.3.4 RH 7.3 Dual Athalon processors
Occasionally, I see Zope gathering very large amounts of real memory. Normally buffering and the like seems to stabalize at around 500MB on a 4GB memory dual processor machine, but occasionally grows to 2.5GB or more. At the same time, CPU usage tends to fully occupy one of the processors for the threads holding all the memory. Clearly there is a problem. Any hints as to where to track down the problem?
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Sun, 2004-09-12 at 13:02, Dennis Allison wrote:
Chris --
Thanks for the assist. I think that I found the source of the problem last night and the the memory leak hypothesis was a cockpit error.
The problem manifested itself when running a find script which was doing an edit cleanup of a lot of stuff (thousands of ZUBBB discussions and ZUBB postings). One of the things the script did was to reset all the ZUBB methods to the default by copying in the half-dozen or so methods present in every instance of the discussions. Zope apparently treats the whole edit as a single transaction and buffers up the changes until it comes time to commit.
It's the developer's responsibility to manage memory during large transactions, yes.
Rewriting the edit script to do things a bit differently and only make changes when they are needed dropped the memory growth and time by a factor of eight or so. While not really anything I'd want to run execpt for the nonce to maintain the system, it did solve my immediate problem. The huge memory that got allocated did get released upon successful completion of the script (and when the script was aborted as well).
Yup.
Is there some mechanism to force a ZODB commit explicitly? If there were, then the edit script would have the structure:
find the thing to edit edit the thing commit the edits
and the resouce demands would be under control.
get_transaction().commit(1) commits a "subtransaction". This is used by, for example the Catalog, when doing batch reindexing. You might want to grep for it in the ZCatalog product. There is probably some surrounding hair to try to reduce memory consumption. Note that explicit transaction control is quite dangerous in Zope if used in the normal course of operations invoked by TTW users (for reasons too obscure to go into here: see recent posts to ZODB-dev). Using it in a script is typically fine though. - C
Note that explicit transaction control is quite dangerous in Zope if used in the normal course of operations invoked by TTW users (for reasons too obscure to go into here: see recent posts to ZODB-dev). Using it in a script is typically fine though.
Noted. & thanks. I guess I should subscribe anbd lurk on ZODB-dev along with the other lists..
On Sunday 12 September 2004 10:25 am, Chris McDonough wrote:
get_transaction().commit(1) commits a "subtransaction". This is used by, for example the Catalog, when doing batch reindexing. You might want to grep for it in the ZCatalog product. There is probably some surrounding hair to try to reduce memory consumption.
Note that explicit transaction control is quite dangerous in Zope if used in the normal course of operations invoked by TTW users (for reasons too obscure to go into here: see recent posts to ZODB-dev). Using it in a script is typically fine though.
Is this the case even for subtransaction commits? I have a particular piece of code that adds a new piece of content to a CMF Site programmatically as the result of a TTW action. During the course of adding the content setId() is called on the object, which fails consistently unless a subtransaction is committed prior to the call (I believe the issue was that the created object wasn't yet stored in the ZODB, so calling setId (which causes a copy) failed). Is this a risky practice? If so, what's the alternative? Thanks. Alec Mitchell
On Mon, 2004-09-13 at 16:28, Alec Mitchell wrote:
On Sunday 12 September 2004 10:25 am, Chris McDonough wrote:
Note that explicit transaction control is quite dangerous in Zope if used in the normal course of operations invoked by TTW users (for reasons too obscure to go into here: see recent posts to ZODB-dev). Using it in a script is typically fine though.
Is this the case even for subtransaction commits?
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3. But they're really only dangerous if you (or someone using your code) inappropriately catches an exception during one of the commits. Inappropriately catching exceptions raised by a transaction commit is a pretty good way to get inconsistent app state in your database. See the ZODB-dev thread for more info. FWIW, this probably won't be solved entirely in any version of Zope 2.7, and maybe not even 2.8 (but hopefully).
I have a particular piece of code that adds a new piece of content to a CMF Site programmatically as the result of a TTW action. During the course of adding the content setId() is called on the object, which fails consistently unless a subtransaction is committed prior to the call (I believe the issue was that the created object wasn't yet stored in the ZODB, so calling setId (which causes a copy) failed).
Can you call setId on it after its attached to another persistent object instead of trying to call setId on it while it's "bare"? But.. actually, why does setId cause a copy? setId seems pretty innocuous at least in name ;-)
Is this a risky practice? If so, what's the alternative? Thanks.
Yes. See above. - C
On Monday 13 September 2004 01:52 pm, Chris McDonough wrote:
On Mon, 2004-09-13 at 16:28, Alec Mitchell wrote:
Is this the case even for subtransaction commits?
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3.
Oh no!
But they're really only dangerous if you (or someone using your code) inappropriately catches an exception during one of the commits. Inappropriately catching exceptions raised by a transaction commit is a pretty good way to get inconsistent app state in your database. See the ZODB-dev thread for more info.
Fortunately that shouldn't happen here. Do you mean that only something like a bare except: that doesn't re-raise the exception would cause a problem. There are no exceptions explicitly caught in my code, but there are calls to Zope/Plone/CMF methods which may cause issues. In particular the setId call from Archetypes calls aq_parent(self).manage_renameObject() which has a bare except, though that just raises a CopyError.
I have a particular piece of code that adds a new piece of content to a CMF Site programmatically as the result of a TTW action. During the course of adding the content setId() is called on the object, which fails consistently unless a subtransaction is committed prior to the call (I believe the issue was that the created object wasn't yet stored in the ZODB, so calling setId (which causes a copy) failed).
Can you call setId on it after its attached to another persistent object instead of trying to call setId on it while it's "bare"? But.. actually, why does setId cause a copy? setId seems pretty innocuous at least in name ;-)
As above, the setId for Archetypes renames the object using OFS.CopySupport.manage_renameObject(), which causes a copy and delete. How would I attach the object to another persistent object during the transaction? Also, why isn't it already attached to the containing folder after being created using self.manage_addProduct[ProductName].addType, where self is the containing folder. Do I explicitly need to do a self._setObject() before the setId call? Or do I need to explicitly acquisition wrap the new object? Thanks in advance. Alec Mitchell
--On Montag, 13. September 2004 15:22 Uhr -0700 Alec Mitchell <apm13@columbia.edu> wrote:
On Monday 13 September 2004 01:52 pm, Chris McDonough wrote:
On Mon, 2004-09-13 at 16:28, Alec Mitchell wrote:
Is this the case even for subtransaction commits?
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3.
Oh no!
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month. Andreas
On Tue, 2004-09-14 at 00:53, Andreas Jung wrote:
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3.
Oh no!
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too! - C
Outstanding. What's still to be done? On Tue, 14 Sep 2004, Chris McDonough wrote:
On Tue, 2004-09-14 at 00:53, Andreas Jung wrote:
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3.
Oh no!
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
- C
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Tue, 2004-09-14 at 01:05, Dennis Allison wrote:
Outstanding. What's still to be done?
I don't think anything special remains except more sessioning testing, actually. And whatever other pet projects people are busily hacking away at before the deadline (I'm not aware of any, but it happens every time ;-) - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Sep 2004 03:11 pm, Chris McDonough wrote:
On Tue, 2004-09-14 at 01:05, Dennis Allison wrote:
Outstanding. What's still to be done?
I don't think anything special remains except more sessioning testing, actually.
Well, that's probably going to be done on our live server starting tomorrow - I'm having a hella time with POSKeyErrors (and SystemErrors on the weekend, which I *know* are fixed in 2.7 CVS) ... so I'm going to be running the bleeding-edge CVS to see if that clears stuff up. Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad. Richard (tired of fixing POSKeyErrors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBRpqkrGisBEHG6TARAi56AJ4oe8J53v1xnjCL1sW0ZkTRYWX+pgCfccoG YL1Me2ughyyu58seLlixt44= =wzwd -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR2yarGisBEHG6TARAh6pAJ9+RThKUeiG3YF6p1l/BB1sLqZc1ACfde9K qUxaEDJQ008lUNsBrKf7QHI= =/x3Q -----END PGP SIGNATURE-----
POSKeyErrors? Do you know which objects are going missing? On Tue, 2004-09-14 at 18:11, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh.
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBR2yarGisBEHG6TARAh6pAJ9+RThKUeiG3YF6p1l/BB1sLqZc1ACfde9K qUxaEDJQ008lUNsBrKf7QHI= =/x3Q -----END PGP SIGNATURE----- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 15 Sep 2004 08:11 am, Richard Jones wrote:
On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh.
I just realised that the error_log object has the REQUEST/SESSION information in it, so my changes would have had no impact. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR76urGisBEHG6TARAnC4AJ9yhKXDefOITqCIOLrt3LHt2Tw3xACfSMsR GMuTsz4b1AkPtC7f7Szvd88= =0NHU -----END PGP SIGNATURE-----
On Wed, 2004-09-15 at 00:01, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 15 Sep 2004 08:11 am, Richard Jones wrote:
On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh.
I just realised that the error_log object has the REQUEST/SESSION information in it, so my changes would have had no impact.
Yikes. That's actually really bad. I will change REQUEST's __str__ to prevent a session data object from being created as a side effect! - C
On Wed, 2004-09-15 at 00:49, Chris McDonough wrote:
On Wed, 2004-09-15 at 00:01, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 15 Sep 2004 08:11 am, Richard Jones wrote:
On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh.
I just realised that the error_log object has the REQUEST/SESSION information in it, so my changes would have had no impact.
Yikes. That's actually really bad. I will change REQUEST's __str__ to prevent a session data object from being created as a side effect!
False alarm, sorry. A session data object doesn't actually get created as a result of str(REQUEST) -- the 'SESSION' item in the request remains "lazy" in this case. Whew. ;-) FYI, if you see something like: SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at f3a87710>> ... in a REQUEST rendering, it indicates a session that is still "lazy", which means a session hasn't actually been created during this request. OTOH, if you see something like: SESSION id: 10952247771174881012, token: 06504336A1fW8kmVMHc, contents: [('count', 0)] ... in the log, it means that a session was created at some point during the request. A session data object always gets created as a side effect of REQUEST.keys(), REQUEST['SESSION'], REQUEST.SESSION, REQUEST.get('SESSION') or REQUEST.has_key('SESSION'), or when sdm.getSessionData() is called explicitly. But unless you did any of the latter in the email, you're no better or worse off than when you started really. Not that you would have been bad off anyway. ;-) It *should* be fine to do transience operations during an exception (the publisher behavior that made it not so was fixed before 2.7.1). The worst thing that should be able to happen is that the standard error message itself errors out with a conflict error, the emergency error handler runs as a result, and renders that conflict error to the requesting user agent. - C
Chris McDonough wrote:
On Tue, 2004-09-14 at 01:05, Dennis Allison wrote:
Outstanding. What's still to be done?
I don't think anything special remains except more sessioning testing, actually. And whatever other pet projects people are busily hacking away at before the deadline (I'm not aware of any, but it happens every time ;-)
I have a somewhat hackish implementation of 'bin/zopectl test Products.FooProduct' nearly ready to go. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
On Tue, 14 Sep 2004, Chris McDonough wrote:
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
Seriously, Chris, what will be fixed in Sessions? I still see occaional instances where session variables suddenly disappear, not a good thing.
Get the latest rundown at http://www.plope.com/Members/chrism/sessioning_redux . Things are looking pretty good AFAICT. On Tue, 2004-09-14 at 01:16, Dennis Allison wrote:
On Tue, 14 Sep 2004, Chris McDonough wrote:
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
Seriously, Chris, what will be fixed in Sessions? I still see occaional instances where session variables suddenly disappear, not a good thing.
Chris, That looks very very good. Given that this is one of our major ongoing bugs and given that we are running under heavy load these days (at least at peak times) I think I will install the CVS version now and plan to upgrade to the beta when it is released. commetns? On Tue, 14 Sep 2004, Chris McDonough wrote:
Get the latest rundown at http://www.plope.com/Members/chrism/sessioning_redux . Things are looking pretty good AFAICT.
On Tue, 2004-09-14 at 01:16, Dennis Allison wrote:
On Tue, 14 Sep 2004, Chris McDonough wrote:
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
Seriously, Chris, what will be fixed in Sessions? I still see occaional instances where session variables suddenly disappear, not a good thing.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris, I looked on cvs.zope.org but could not find anything that looked like 2.7.3--was I looking in the wrong place? -d On Tue, 14 Sep 2004, Chris McDonough wrote:
Get the latest rundown at http://www.plope.com/Members/chrism/sessioning_redux . Things are looking pretty good AFAICT.
On Tue, 2004-09-14 at 01:16, Dennis Allison wrote:
On Tue, 14 Sep 2004, Chris McDonough wrote:
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
Seriously, Chris, what will be fixed in Sessions? I still see occaional instances where session variables suddenly disappear, not a good thing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Sep 2004 03:49 pm, Dennis Allison wrote:
Chris, I looked on cvs.zope.org but could not find anything that looked like 2.7.3--was I looking in the wrong place?
It's the Zope module, with tag Zope-2_7-branch. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBRptzrGisBEHG6TARApMtAJsF9Wfwivu8wz5Jk1stMGYDmkubsACfU/oU RiF0So1Y4nNjO6GvkYfsMz8= =viBJ -----END PGP SIGNATURE-----
Thanks... duh... it's late here. On Tue, 14 Sep 2004, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 14 Sep 2004 03:49 pm, Dennis Allison wrote:
Chris, I looked on cvs.zope.org but could not find anything that looked like 2.7.3--was I looking in the wrong place?
It's the Zope module, with tag Zope-2_7-branch.
Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBRptzrGisBEHG6TARApMtAJsF9Wfwivu8wz5Jk1stMGYDmkubsACfU/oU RiF0So1Y4nNjO6GvkYfsMz8= =viBJ -----END PGP SIGNATURE-----
You want the "Zope-2_7-branch" but I haven't yet checked the various changes listen on the plope.com page under "In my Head" into that branch, tho. This includes one or two major bugfixes. If you're really manly, you can check out the "chrism-pre273-branch" of the Transience product (it's not a tag that is used for Zope itself). That's where all the work is happening before it goes into the 2.7 branch. On Tue, 2004-09-14 at 01:49, Dennis Allison wrote:
Chris, I looked on cvs.zope.org but could not find anything that looked like 2.7.3--was I looking in the wrong place? -d
On Tue, 14 Sep 2004, Chris McDonough wrote:
Get the latest rundown at http://www.plope.com/Members/chrism/sessioning_redux . Things are looking pretty good AFAICT.
On Tue, 2004-09-14 at 01:16, Dennis Allison wrote:
On Tue, 14 Sep 2004, Chris McDonough wrote:
Before everyone starts grouching: 2.7.3b1 will be released by the end of the month.
Yup. Sessions might even work too!
Seriously, Chris, what will be fixed in Sessions? I still see occaional instances where session variables suddenly disappear, not a good thing.
Dennis Allison wrote at 2004-9-11 22:33 -0700:
... Memory Leak ... Clearly there is a problem. Any hints as to where to track down the problem?
I often succeed by carefully looking at the reference counts in "Control_Panel --> Debug information". You need to flush the ZODB cache to get most useful reference count information. After such a flush almost all reference counts should be small. The one that are not a part of a leak. -- Dieter
participants (7)
-
Alec Mitchell -
Andreas Jung -
Chris McDonough -
Dennis Allison -
Dieter Maurer -
Richard Jones -
Tres Seaver