Re: [Zope-dev] cPickleCache endless loop...

2004-01-27 Thread Chris Withers
Paul Winkler wrote:

I don't know what your intention is there, but fwiw, if
what you're *really* interested in is the object being
marked for deletion in the ZODB, you can use:
I'm pretty sure that only works in Zope,
so? the O.P. was about zope, and this IS the zope-dev list...
Yup, but ZODB != Zope...

Chris

___
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] ConflictError in BTreeFolder2

2004-01-27 Thread Chris Withers
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...

2004-01-27 Thread Mario Lorenz
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

2004-01-27 Thread Leonardo Rochael Almeida
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

2004-01-27 Thread Tres Seaver
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

2004-01-27 Thread Fred L. Drake, Jr.

Tres Seaver writes:
  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.

And I've simplified it.  ;-)  Thanks for following up on this.


  -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 )


Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches

2004-01-27 Thread Leonardo Rochael Almeida
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

2004-01-27 Thread Fred L. Drake, Jr.

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)

2004-01-27 Thread Brian Lloyd
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...

2004-01-27 Thread Toby Dickenson
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] ConflictError in BTreeFolder2

2004-01-27 Thread Florent Guillaume
   I've fixed BTreeFolder2 to properly re-raise ConflictError in _delObject 
   [...]
 
  Are these patches available anywhere?
 
 He's fixed them in CVS:
 
 http://cvs.zope.org/Products/BTreeFolder2/BTreeFolder2.py.diff?r1=1.19r2=1.20
 
  Have you let Shane know?
 
 Assuming Shane listens to zope CVS mail notifications, yes :-)

Yes and I posted in zope-dev to let people know.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
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...

2004-01-27 Thread Toby Dickenson
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 -