Inavlid Refernce Counts in Temporary Storage
Hi All, I have an RDBMS application, which resides in a Plone site, but uses only Zope techniques. Aside from Plone, the only use of the ZODB is to hold session variables for users (search parameters etc.), and the load on that part of the system is very light (10 users, accessing the script in question once every couple of minutes at the most). The session variables are written by simple TTW Python scripts, and read back by TALES expressions - all very simple. For the last three days, we have been plagued by slowdowns and temporary lock-ups, which have on a couple of score occasions culminated in a Conflict Error, indicting transactional problems in the temporary storage. On four or five occasions, Zope has apparently "locked up", and a restart has been required. Today, I am seeing errors when I try to pack this storage: - ------ 2006-07-13T15:09:11 ERROR Zope.SiteErrorLog http://10.0.0.7:8080/Control_Panel/Database/temporary/manage_pack Traceback (most recent call last): File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\ZPublisher\Publish.py", line 114, in publish request, bind=1) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s<cr> to step into published object. File "D:\Program Files\Enfold Server\Zope\lib\python\App\ApplicationManager.py", line 426, in manage_pack t=db.pack(t) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\ZODB\DB.py", line 634, in pack self._storage.pack(t, referencesf) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\tempstorage\TemporaryStorage.py", line 350, in pack self._takeOutGarbage(oid) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\tempstorage\TemporaryStorage.py", line 321, in _takeOutGarbage raise ReferenceCountError, ( ReferenceCountError: An error occured while decrementing a reference to an object in the commit phase. The object's reference count was below zero. (Oid '\x00\x00\x00\x00\x00\x00\x00;' had refcount -1) ------ This seems to indicate that the temporary storage is corrupt in some way - am I right? If so, what do I do about it? Could this indicate a RAM or disk problem, since the application has not changed significantly, at least at the level of my TTW code? Any input welcome - aside from this simple use of the session, I never have to manipulate the ZODB, so this is pretty new to me! -- Regards, PhilK "Human language continually changes, innit." - Stephen Juan
Philip Kilner wrote at 2006-7-13 15:30 +0100:
... t=db.pack(t) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\ZODB\DB.py", line 634, in pack self._storage.pack(t, referencesf) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\tempstorage\TemporaryStorage.py", line 350, in pack self._takeOutGarbage(oid) File "D:\PROGRA~1\ENFOLD~1\Zope\lib\python\tempstorage\TemporaryStorage.py", line 321, in _takeOutGarbage raise ReferenceCountError, ( ReferenceCountError: An error occured while decrementing a reference to an object in the commit phase. The object's reference count was below zero. (Oid '\x00\x00\x00\x00\x00\x00\x00;' had refcount -1)
You may see a bug in the "pack" implementation for "TemporaryStorage". Few people will probably try to "pack" a TemporaryStorage... Are you shure to need it? -- Dieter
Hi Dieter, Dieter Maurer wrote:
You may see a bug in the "pack" implementation for "TemporaryStorage".
Aha - well, my Zope version is 2.8.6 - I'll dig to see if this version is affected.
Few people will probably try to "pack" a TemporaryStorage... Are you shure to need it?
No, not as such - I'm having problems with "Conflict Errors", when I try to store variables in the session. The system has not changed in any way that I can see is relevant, and is not under heavy load (<10 users accessing the pages in question), so I was trying to examine the behaviour of the temporary storage and satisfy myself that is was healthy.
From what you say, it may be that this error is entirely down to the pack bug, so I'm back to trying to figure out how to troubleshoot the conflict error.
-- Regards, PhilK "Human language continually changes, innit." - Stephen Juan
On 7/14/06, Philip Kilner <phil@xfr.co.uk> wrote:
For the last three days, we have been plagued by slowdowns and temporary lock-ups, which have on a couple of score occasions culminated in a Conflict Error, indicting transactional problems in the temporary storage. On four or five occasions, Zope has apparently "locked up", and a restart has been required.
The conflict error's may well just be a by-product of the slow down. Roughly speaking, the longer a request takes the higher the chances are of conflict error. There are various tools for trying to see what zope is doing. Google for: debug spinning zope. cheers michael
participants (3)
-
Dieter Maurer -
Michael Dunstan -
Philip Kilner