Re: [Zope-dev] ConflictError in BTreeFolder2
Are these patches available anywhere? Have you let Shane know? Chris Florent Guillaume wrote: FYI: I've fixed BTreeFolder2 to properly re-raise ConflictError in _delObject and not swallow it during beforeDelete cleanups. This is the same fix that was done in ObjectManager. Florent ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] cPickleCache endless loop...
Am 26. Jan 2004, um 12:22:43 schrieb Tim Peters: It's actually that the number of __del__-resurrecting objects *plus* the number of non-ghostifiable objects in cache is larger than the cache target size, right? Yes, but when you push the minimize button, the cache target size is 0. Nonwithstanding our code (it was mostly debugging/tracing functionality anyway, so it was easy to fix), it is just that with Zope 2.5, it seemed to work (at least I never got a bug report back then) so it took us a while to track this down. Especially since we had just moved to RHEL3, so we were expecting more like a threading issue... Given that this property is not that widely published (in the various tutorials etc.), I wonder if it might be a good idea to improve that loop check code, and walk through the ring not more than once, using a counter, and not the comparison vs. the ring start, which, as we have seen, may be a target that moves too quickly. Similarly wink, except that if there's a large number of non-ghostifiable objects (more than the cache target size), then only one __del__-resurrected object is enough to provoke an infinite loop. Yes, this is exactly what happened here. Mario -- Mario Lorenz EMail: [EMAIL PROTECTED] Tel: 03774 6625-78 Technik Netze Handy: 0160 3151600 km3 teledienst GmbH Fax: 03774 6625-79 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
Hi, There's a recent entry in the 2.6 branch from fred stating: types don't have a guaranteed truth value, so check that it isn't None the diff is here: http://cvs.zope.org/Zope/lib/python/ZTUtils/Zope.py.diff?r1=1.10.6.3r2=1.10.6.4only_with_tag=Zope-2_6-branch This same fix needs to be applied to at least the 2.7 branch and HEAD, probaly other branches too, but I haven't checked. Should I file a bug for this? Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
Leonardo Rochael Almeida wrote: There's a recent entry in the 2.6 branch from fred stating: types don't have a guaranteed truth value, so check that it isn't None the diff is here: http://cvs.zope.org/Zope/lib/python/ZTUtils/Zope.py.diff?r1=1.10.6.3r2=1.10.6.4only_with_tag=Zope-2_6-branch This same fix needs to be applied to at least the 2.7 branch and HEAD, probaly other branches too, but I haven't checked. The 2.7 branch and the head are the only two other active branches; I just checked in a fix which removes the pre-2.3 compatibility code. Should I file a bug for this? Nope, at least not this time. Next time you could follow up to 1203, noting the problem. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
On Tue, 2004-01-27 at 12:42, Tres Seaver wrote: [...] The 2.7 branch and the head are the only two other active branches; I just checked in a fix which removes the pre-2.3 compatibility code. Funny, with all the talk about 2.8 including only the ZODB work and fixes, I thought we'd have a 2.8 branch by now... :-) -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
Leonardo Rochael Almeida writes: Funny, with all the talk about 2.8 including only the ZODB work and fixes, I thought we'd have a 2.8 branch by now... :-) Yeah, we're kind of call that the trunk for now, so we pick up the general bug fixes as well. Too many actual (active) branches makes for true pain in managing patches. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Call for testing (2.6.4 / 2.7.0)
Hi all - Tres and I have been working to merge some final fixes, and I'd like to be able to make rc2 releases for 2.6.4 and 2.7.0 tomorrow. In the meantime, it would be helpful for anyone who runs from the 2.6 or 2.7 branches in CVS to update and let us know if you have any unresolved problems. It would be especially helpful for those who were having trouble with things like workflow scripts under the rc1 releases to give this a shot and let us know if the trouble is resolved. **Note that you need to rebuild the C extensions, due to a fix to cAccessControl. Be sure to do this before reporting any lingering issues!** Thanks, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] cPickleCache endless loop...
On Tuesday 27 January 2004 19:08, Tim Peters wrote: Maybe Toby remembers which release(s) of ZODB the current cache implementation first appeared in Zope 2.6 -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] cPickleCache endless loop...
On Tuesday 27 January 2004 09:39, Mario Lorenz wrote:
Given that this property is not that widely published (in the various
tutorials etc.), I wonder if it might be a good idea to improve that loop
check code, and walk through the ring not more than once, using a counter,
and not the comparison vs. the ring start, which, as we have seen, may be a
target that moves too quickly.
You got me curious
The attached patch to 2.6 uses an extra temporary ring node to mark where
scanning should stop. Normally this will be right next to the home node, and
behaviour is unchanged. Any of these troublesome objects that move themselves
to the top of the LRU list *during* the scan will end up *after* the scan
terminator node, and therefore do not get rescanned.
This works for me on 2.6, which is the only branch Im set up to use at the
moment.
--
Toby Dickenson
? diff
? diff2
Index: cPickleCache.c
===
RCS file: /cvs-repository/Zope/lib/python/ZODB/Attic/cPickleCache.c,v
retrieving revision 1.68.10.3
diff -c -4 -r1.68.10.3 cPickleCache.c
*** cPickleCache.c 30 Apr 2003 17:03:34 - 1.68.10.3
--- cPickleCache.c 27 Jan 2004 23:02:06 -
***
*** 216,224
#endif
static int
! scan_gc_items(ccobject *self,int target)
{
/* This function must only be called with the ring lock held,
because it places a non-object placeholder in the ring.
*/
--- 216,224
#endif
static int
! scan_gc_items(ccobject *self,int target,CPersistentRing *terminal)
{
/* This function must only be called with the ring lock held,
because it places a non-object placeholder in the ring.
*/
***
*** 265,281
return -1;
}
#endif
! /* back to the home position. stop looking */
! if (here == self-ring_home)
! return 0;
/* At this point we know that the ring only contains nodes
! from persistent objects, plus our own home node. We know
! this because the ring lock is held. We can safely assume
! the current ring node is a persistent object now we know it
! is not the home */
object = OBJECT_FROM_RING(self, here, scan_gc_items);
if (!object)
return -1;
--- 265,288
return -1;
}
#endif
! /* reached the end position. stop looking */
! if (here == terminal)
! return 0;
!
! /* back to the home position. should not happen */
! if (here == self-ring_home) {
! PyErr_SetString(PyExc_RuntimeError,
! reached home before terminal, in scan_gc_items);
! return -1;
! }
/* At this point we know that the ring only contains nodes
! from persistent objects, plus our own home node, plus the
!terminal node. We know this because the ring lock is held.
!We can safely assume the current ring node is a persistent
!object now. */
object = OBJECT_FROM_RING(self, here, scan_gc_items);
if (!object)
return -1;
***
*** 325,332
--- 332,343
static PyObject *
lockgc(ccobject *self, int target_size)
{
+ int error;
+ CPersistentRing terminal;
+
+
/* This is thread-safe because of the GIL, and there's nothing
* in between checking the ring_lock and acquiring it that calls back
* into Python.
*/
***
*** 338,350
if (IS_RING_CORRUPT(self, pre-gc))
return NULL;
ENGINE_NOISE();
self-ring_lock = 1;
! if (scan_gc_items(self, target_size)) {
! self-ring_lock = 0;
! return NULL;
! }
self-ring_lock = 0;
ENGINE_NOISE(\n);
if (IS_RING_CORRUPT(self, post-gc))
return NULL;
--- 349,376
if (IS_RING_CORRUPT(self, pre-gc))
return NULL;
ENGINE_NOISE();
self-ring_lock = 1;
!
! /* insert a placeholder just before the head node. This will be used to
! * terminate the scan_gc_items loop. Items touched during the
! * deactivation run will get inserted between the head and this terminal
! * node, and will not get re-scanned. */
! terminal.next = self-ring_home;
! terminal.prev = self-ring_home.prev;
! self-ring_home.prev-next = terminal;
! self-ring_home.prev = terminal;
!
! error = scan_gc_items(self, target_size, terminal);
!
! /* unlink the placeholder from the ring */
! terminal.next-prev = terminal.prev;
! terminal.prev-next = terminal.next;
!
self-ring_lock = 0;
+ if (error)
+ return NULL;
+
ENGINE_NOISE(\n);
if (IS_RING_CORRUPT(self, post-gc))
return NULL;
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
