Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
On Wed, 2004-03-03 at 22:20, Casey Duncan wrote: > > > for key in list(self._data.keys(None, max_ts)): > > > assert(key <= max_ts) > > > STRICT and _assert(self._data.has_key(key)) > > > for v in self._data[key].values(): > > > to_notify.append(v) > > > del self._data[key] > > Maybe you could use items() and two loops instead; > > to_rm = [] > for key, val in self._data.items(None, max_ts): > for v in val.values(): > to_notify.append(v) > to_rm.append(key) > for key in to_rm: > try: > del self._data[key] > except Keyerror: >pass # Somebody else deleted it first > > I don't think that could raise a KeyError... Well, the real bit of magic there is the "try.. except KeyError: pass" stanza. Believe me, I'm tempted to stick that in, but this is the kind of voodoo that got me in to a lot of trouble in the older version of this code (there was reams upon reams of voodoo in the old code), so I'd really rather just figure out why the code is failing in the first place. I'd just rather not mask the problem until I understand the cause. That may never happen, of course, but a man can dream. - C ___ 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: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
Chris McDonough wrote at 2004-3-3 04:55 -0500: >(boldly crossposting this to zodb-dev, please respond on one list or the >other but not both) > >That error *appears* to be caused by reaching a state that is impossible >to reach. The code in question is: > >for key in list(self._data.keys(None, max_ts)): >assert(key <= max_ts) >STRICT and _assert(self._data.has_key(key)) >for v in self._data[key].values(): >to_notify.append(v) >del self._data[key] > >The line that says "for v in self._data[key].values()" is the line that >throws the KeyError. But it should be impossible for the code to throw >a KeyError for the expression "self._data[key]" because the "keys" >method of the _data IOBTree just told us that the key named by "key" was >one of its keys via the range search; it should be an invariant. If we had a low conflict connection, I would understand how this could happen: All BTree leaves are chained together. The "keys" method uses this chain to enumerate the keys. "[]" on the other hand, uses the tree structure to locate its key. Assume that a parallel thread removes a key and commits the transaction while we are in the for loop above. We may read the old state (with the later deleted key) for "keys". During the "for", we receive invalidations for the nodes affected by the deletion. When we access "[key]" we may try to load a tree node which is not yet in the ZODB cache and meanwhile invalidated. When we suppress the resulting "ReadConflictError", we may not find "key" (as it is by now deleted). In my "Transience" implementation, I ignore this exceptional case. I do use a low conflict connection and have to be prepared for this situation. Furthermore, the situation is not problematic: I want to determine sessions that should be deleted. Someone else already did it -- this is fine. No need to do it twice... -- Dieter ___ 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: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
On Wed, 2004-03-03 at 04:55, Chris McDonough wrote: > (boldly crossposting this to zodb-dev, please respond on one list or the > other but not both) > > That error *appears* to be caused by reaching a state that is impossible > to reach. The code in question is: > > for key in list(self._data.keys(None, max_ts)): > assert(key <= max_ts) > STRICT and _assert(self._data.has_key(key)) > for v in self._data[key].values(): > to_notify.append(v) > del self._data[key] I don't have much context for this question. It's definitely the case that a corrupt BTree there are keys you can reach using keys(), which follows the bucket next pointers, that can't reach using a lookup, which follows child pointers down through the interior nodes. If you could call the check functions on the BTrees in question. That's object._check() to check C internals and BTrees.check.check() to check value based consistency. So how is the BTree is question used? If the test is failing here, it seems most likely that the BTree was corrupted by a write somewhere else. Jeremy ___ 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] Zope 2.7 breaks auto refresh
On Wed, 2004-03-03 at 08:42, Santi Camps wrote:
> Hi again,
>
> I've this traceback using Zope 2.7.0 final:
>
> Module ZPublisher.Publish, line 163, in publish_module_standard
> * Module ZPublisher.Publish, line 127, in publish
> * Module Zope.App.startup, line 203, in zpublisher_exception_hook
> * Module ZPublisher.Publish, line 104, in publish
> * Module Zope.App.startup, line 221, in commit
> * Module ZODB.Transaction, line 233, in commit
> * Module ZODB.Transaction, line 348, in _commit_objects
> * Module ZODB.Connection, line 435, in commit
> __traceback_info__: (('Products.Transience.TransientObject',
> 'TransientObject'), '\x00\x00\x00\x00\x00\x00\x008', '')
I don't understand this traceback entirely. What is the exception that
is being raised? Also, the last line in the traceback doesn't match a
line on my copy of ZODB/Connection.py. (I've got revision 1.98.4.5.)
> I've tryied to understand the problem. It seems that now Trasicience
> uses a different ZODB connection (using DBTab), and I think this is the
> cause of the problem.
>
> In Zope/App/startup.py, there is the following lines:
>
> # Initialize the app object
> application = app()
> OFS.Application.initialize(application)
> if Globals.DevelopmentMode:
> # Set up auto-refresh.
> from App.RefreshFuncs import setupAutoRefresh
> setupAutoRefresh(application._p_jar)
> application._p_jar.close()
>
>
> This handles the autoRefresh machinery to the main Connection, but I've
> not found anywhere the same has been done with temporary Connection.
>
> But in the ZODB/Connection.py there is a global_code_timestamp used to
> compare all Connections _code_timestamp attribute.
>
> Then, when the Connection tries to commit, as the _code_timestamp of
> Trasicience connection hasn't been updated, the problem appears. Almost
> is what I think.
I'm not very familiar with the App.RefreshFuncs code, but I think I can
offer some generic comments. setupAutoRefresh() calls
ZODB.Connection.updateCodeTimestamp() which will cause every Connection
to reset its cache the next time it is opened. It wouldn't be safe to
reset the cache at other times, because application code could have a
reference to existing objects.
I don't know how all this affects the Transience connection. When is it
opened and closed?
Jeremy
___
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] Zope 2.7 breaks auto refresh
> I don't understand this traceback entirely. What is the exception that
> is being raised? Also, the last line in the traceback doesn't match a
> line on my copy of ZODB/Connection.py. (I've got revision 1.98.4.5.)
>
Sorry, the full Traceback is this one (the previous one has a modified
version of Connection.py to add some LOGs):
Traceback (innermost last):
* Module ZPublisher.Publish, line 163, in publish_module_standard
* Module ZPublisher.Publish, line 127, in publish
* Module Zope.App.startup, line 203, in zpublisher_exception_hook
* Module ZPublisher.Publish, line 104, in publish
* Module Zope.App.startup, line 221, in commit
* Module ZODB.Transaction, line 233, in commit
* Module ZODB.Transaction, line 348, in _commit_objects
* Module ZODB.Connection, line 425, in commit
__traceback_info__: (('Products.Transience.TransientObject',
'TransientObject'), '\x00\x00\x00\x00\x00\x00\x00)', '')
ValueError: Cache values may only be in one cache. (Also, an error
occurred while attempting to render the standard error message.)
After that, any try to work with the applications raises this other one:
Traceback (innermost last):
* Module ZPublisher.Publish, line 163, in publish_module_standard
* Module ZPublisher.Publish, line 127, in publish
* Module Zope.App.startup, line 203, in zpublisher_exception_hook
* Module ZPublisher.Publish, line 104, in publish
* Module Zope.App.startup, line 221, in commit
* Module ZODB.Transaction, line 233, in commit
* Module ZODB.Transaction, line 348, in _commit_objects
* Module ZODB.Connection, line 425, in commit
__traceback_info__: (('BTrees.OOBTree', 'OOBTree'),
'\x00\x00\x00\x00\x00\x00\x00\x0e', '')
ValueError: Cache values may only be in one cache. (Also, an error
occurred while attempting to render the standard error message.)
> > I've tryied to understand the problem. It seems that now Trasicience
> > uses a different ZODB connection (using DBTab), and I think this is the
> > cause of the problem.
> >
> > In Zope/App/startup.py, there is the following lines:
> >
> > # Initialize the app object
> > application = app()
> > OFS.Application.initialize(application)
> > if Globals.DevelopmentMode:
> > # Set up auto-refresh.
> > from App.RefreshFuncs import setupAutoRefresh
> > setupAutoRefresh(application._p_jar)
> > application._p_jar.close()
> >
> >
> > This handles the autoRefresh machinery to the main Connection, but I've
> > not found anywhere the same has been done with temporary Connection.
> >
> > But in the ZODB/Connection.py there is a global_code_timestamp used to
> > compare all Connections _code_timestamp attribute.
> >
> > Then, when the Connection tries to commit, as the _code_timestamp of
> > Trasicience connection hasn't been updated, the problem appears. Almost
> > is what I think.
>
> I'm not very familiar with the App.RefreshFuncs code, but I think I can
> offer some generic comments. setupAutoRefresh() calls
> ZODB.Connection.updateCodeTimestamp() which will cause every Connection
> to reset its cache the next time it is opened. It wouldn't be safe to
> reset the cache at other times, because application code could have a
> reference to existing objects.
>
> I don't know how all this affects the Transience connection. When is it
> opened and closed?
>
> Jeremy
I think the error is produced after the second store in the SESSION
variable. Perhaps the problem is that the temporary Connection is not
closed and openned right. I will continue debugging
Thanks for your answer
--
Santi Camps
http://zetadb.sourceforge.net
___
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: Broken Unittest
Christian Theune wrote: ... the problem ... seems fixed by the changed test. Yay! So I'll mark this as "resolved" in my mental collector. Thanks for bringing this to my attention, and sorry it caused you grief. Gary ___ 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] Zope 2.7 breaks auto refresh
Hi again,
I've this traceback using Zope 2.7.0 final:
Module ZPublisher.Publish, line 163, in publish_module_standard
* Module ZPublisher.Publish, line 127, in publish
* Module Zope.App.startup, line 203, in zpublisher_exception_hook
* Module ZPublisher.Publish, line 104, in publish
* Module Zope.App.startup, line 221, in commit
* Module ZODB.Transaction, line 233, in commit
* Module ZODB.Transaction, line 348, in _commit_objects
* Module ZODB.Connection, line 435, in commit
__traceback_info__: (('Products.Transience.TransientObject',
'TransientObject'), '\x00\x00\x00\x00\x00\x00\x008', '')
The error is caused during the "auto refresh" hook. If auto refresh is
disabled, all works fine. I've seen that there is a bug in the
collector about this issue: http://zope.org/Collectors/Zope/1010
I've tryied to understand the problem. It seems that now Trasicience
uses a different ZODB connection (using DBTab), and I think this is the
cause of the problem.
In Zope/App/startup.py, there is the following lines:
# Initialize the app object
application = app()
OFS.Application.initialize(application)
if Globals.DevelopmentMode:
# Set up auto-refresh.
from App.RefreshFuncs import setupAutoRefresh
setupAutoRefresh(application._p_jar)
application._p_jar.close()
This handles the autoRefresh machinery to the main Connection, but I've
not found anywhere the same has been done with temporary Connection.
But in the ZODB/Connection.py there is a global_code_timestamp used to
compare all Connections _code_timestamp attribute.
Then, when the Connection tries to commit, as the _code_timestamp of
Trasicience connection hasn't been updated, the problem appears. Almost
is what I think.
If anybody can put me in the right direction I can try to provide a
patch. What do you think ? Which is the best way to solve this
problem?
Thanks a lot
--
Santi Camps
http://zetadb.sourceforge.net
___
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: Execution context
Thank you for your help I would like to overrite some properties in my product with a know property (Maestro) For example I define an object: ObjectA PropertyA PropertyB PropertyC Maestro -> this property has a transversal path to ObjectB ObjectB PropertyD Then I would like to call ObjectA.PropertyD -> these code calls ObjectB.Property With these code I would like to construct a soft link mechanism I try to override the __bobo_traverse__ with these code: def __bobo_traverse__(self, Request, Name): Maestro = getattr(self, '.Maestro', None) if Maestro is not None: obj = self.unrestrictedTraverse(Maestro.contenido) Acquirido = obj.__of__(self) return getattr(Acquirido, Name) return getattr(self, Name) these override works fine but is not recursive in the Maestro structures If I use these other override : def __bobo_traverse__(self, Request, Name): """Propiedad""" Obj = self Maestro = getattr(Obj, '.Maestro', None) Paso = 1 while Maestro is not None: Obj = self.restrictedTraverse(Maestro.contenido).__of__(self) Maestro = getattr(Obj, '.Maestro', None) Paso += 1 if Paso == 15: break if hasattr(Obj, Name): return getattr(Obj, Name) return getattr(self, Name) The recursive Maestro mechanism works fine but in the ZMI I obtain the object in the Maestro structure. For me is an error because I can't see the real content of the object Do you understand my problem? Thanks again!!! PD: sorry for my english! - Original Message - From: "Tres Seaver" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 03, 2004 3:33 AM Subject: [Zope-dev] Re: Execution context > Garito wrote: > > Can I know the execution contexto of an object? > > > > I would like to know if the object is call by ZMI or DTML or Page Templates etc > > > > is it posible? > > Perhaps; I am not sure I can see why it would be *desirable*. Given > that Scripts, DTMLMethods, etc., try pretty hard to push themselves onto > the execution stack just as though they were methods, you could probably > introspect the result of calling 'sys._getframe(1)' to figure out what > kind of thing called you. > > From the Python Cookbook, #14.7: > > >>> def whoami(): > ... """ Return the name of the calling function. > ... """ > ... import sys > ... return sys._getframe(1).f_code.co_name > ... > >>> def foobar(): > ... print whoami() > ... > >>> foobar() > foobar > > > 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 ) > ___ 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: running test.py with instance_home products.
Dieter Maurer wrote: Chris McDonough wrote at 2004-3-1 21:17 -0500: Has anyone found a reasonable strategy for using Zope's test.py to test products that are installed outside the Zope software home? I try running it from the software home and using the --dir option to point it to where my product is, but it tells me it can't find any tests. I do regularly. I use "... test.py --lib path_to_myProduct ..." Dieter, are you installing your products under $SOFTWARE_HOME/Products? Because otherwise I don't see anything in test.py which invokes the FindHomes machinery to stitch $INSTANCE_HOME/Products into the __path__ of the Products module. 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 )
[Zope-dev] dev.zope.org
Hi, could somebody update the dev.zope.org FrontPage to reflect Zope 2.8 beeing the version in development? I have not enough permissions to do this. Cheers, Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - [EMAIL PROTECTED] fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366 signature.asc Description: This is a digitally signed message part ___ 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] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please
[EMAIL PROTECTED] wrote: * Module Products.Transience.Transience, line 419, in _gc KeyError: 1078236460 (on the other Chris's behalf) wagh! Chris ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
(boldly crossposting this to zodb-dev, please respond on one list or the other but not both) That error *appears* to be caused by reaching a state that is impossible to reach. The code in question is: for key in list(self._data.keys(None, max_ts)): assert(key <= max_ts) STRICT and _assert(self._data.has_key(key)) for v in self._data[key].values(): to_notify.append(v) del self._data[key] The line that says "for v in self._data[key].values()" is the line that throws the KeyError. But it should be impossible for the code to throw a KeyError for the expression "self._data[key]" because the "keys" method of the _data IOBTree just told us that the key named by "key" was one of its keys via the range search; it should be an invariant. Note that in the line above that starts "STRICT and _assert...", I do the paranoid check there as there *have* been cases where BTrees range searches lied in the past. STRICT is not true in your case (it's turned off), so that check never gets run on your system, but if it had, it might have raised an assertion error. I haven't been able to provoke that kind of thing in my own stress tests, unfortunately. I have been proven to be at fault about this sort of thing before, but I've been a good boy and I believe I've applied all of the lessons I learned in the past to the newest code, so I unfortunately again have to reach the conclusion that there is something afoul in the BTrees code, provoked only under high stress scenarios. It's also appears to be very difficult to reproduce. In the end, this means to you that... well.. you've got two choices. a) continue using ZODB-based sessions and helping us (me) to track it down, living with the consequences of the errors in the meantime or b) use a different session implementation. I would prefer "a" but I do need to warn you that this might *never* get solved because the failure mode appears to be so intermittent that it's extremely expensive (in the dollars-and-cents sense) to pin down and ultimately fix, and that may prevent me (and ZC) from doing so. But with a lot of help from other interested people (like yourself) we may be able to coax the failure out of obscurity and squish it without breaking the bank. ;-) Assuming you're interested, what can you do? Well, you could find out a little about the BTrees module in Zope CVS, particularly the "check" module which has code to check a BTree for corruption, and instrument the Transience code to run the check code in the places it seems to be coming up with errors before bombing out. If it's not corrupt, well.. I'm not sure what that means, but it would appear to be a problem with the BTrees range search functions. If it is corrupt, it might exonerate the range search functions. Rinse, lather, repeat with other checks in the code, such as reporting the internal state of the BTree when the error occurs (which I've forgotten how to do, but a maillist search should help), providing information about when conflict errors were raised right before the error, and so on. It's very difficult to provide a concrete "type this, type that" set of steps for this sort of thing due to the latency involved in remote debugging an extremely hard to reproduce failure, so if you want to help best, since you're the person who has access to the machine where the failure appears to be reproducible (and hopefully the motive to want to fix it), you should familiarize yourself with the Transience code and the BTrees APIs and use a bit of inductive logic to help me isolate the problem. If you'd rather not, I can understand that too. ;-) HTH, - C On Wed, 2004-03-03 at 03:18, [EMAIL PROTECTED] wrote: > Chris, > > No, just a few minutes ago I got this again: > > Time 2004/03/03 07:45:04.662 GMT > User Name (User Id) Anonymous User (None) > Request URL http://www.chalkface.com/catalog/html/custom/index_html > Exception TypeKeyError > Exception Value 1078236460 > > Traceback (innermost last): > > * Module ZPublisher.Publish, line 100, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 40, in call_object > * Module OFS.DTMLDocument, line 128, in __call__ > > URL: http://www.chalkface.com/custom/index_html/manage_main > Physical Path:/www.chalkface.com/ZWarehouse_0.8/custom/index_html > * Module DocumentTemplate.DT_String, line 474, in __call__ > * Module OFS.DTMLDocument, line 121, in __call__ > > URL: http://www.chalkface.com/custom/index.html/manage_main > Physical Path:/www.chalkface.com/ZWarehouse_0.8/custom/index.html > * Module DocumentTemplate.DT_String, line 474, in __call__ > * Module DocumentTemplate.DT_Let, line 76, in render > * Module OFS.DTMLDocument, line 121, in __call__ > > URL: > http://www.chalkface.com/catalog/html/zwarehouse_html_header/manage_m
Re: [Zope-dev] Re: Broken Unittest
On Tue, 2004-03-02 at 21:28, Gary Poster wrote: > Hi Christian. What are the (possibly) pertinent elements to the changes > in your sandbox? Haven't been correlating to the problem which seems fixed by the changed test. The changes are two minor usability tweaks in the ZMI and the post traversal hook for Zope 2.8. Cheers, Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - [EMAIL PROTECTED] fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366 signature.asc Description: This is a digitally signed message part ___ 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] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please
Chris, No, just a few minutes ago I got this again: Time2004/03/03 07:45:04.662 GMT User Name (User Id) Anonymous User (None) Request URL http://www.chalkface.com/catalog/html/custom/index_html Exception Type KeyError Exception Value 1078236460 Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module OFS.DTMLDocument, line 128, in __call__ URL: http://www.chalkface.com/custom/index_html/manage_main Physical Path:/www.chalkface.com/ZWarehouse_0.8/custom/index_html * Module DocumentTemplate.DT_String, line 474, in __call__ * Module OFS.DTMLDocument, line 121, in __call__ URL: http://www.chalkface.com/custom/index.html/manage_main Physical Path:/www.chalkface.com/ZWarehouse_0.8/custom/index.html * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_Let, line 76, in render * Module OFS.DTMLDocument, line 121, in __call__ URL: http://www.chalkface.com/catalog/html/zwarehouse_html_header/manage_main Physical Path:/www.chalkface.com/ZWarehouse_0.8/catalog/html/zwarehouse_html_header * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_Util, line 201, in eval __traceback_info__: cart_functions * Module , line 1, in * Module Shared.DC.Scripts.Bindings, line 306, in __call__ * Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec * Module Products.PythonScripts.PythonScript, line 318, in _exec * Module None, line 16, in setSessionByRequest.py Line 16 * Module ZPublisher.HTTPRequest, line 1218, in __getattr__ * Module ZPublisher.HTTPRequest, line 1178, in get * Module Products.Sessions.SessionDataManager, line 93, in getSessionData * Module Products.Sessions.SessionDataManager, line 180, in _getSessionDataObject * Module Products.Transience.Transience, line 491, in new_or_existing * Module Products.Transience.Transience, line 322, in get * Module Products.Transience.Transience, line 198, in _move_item * Module Products.Transience.Transience, line 419, in _gc KeyError: 1078236460 On Wed, 3 Mar 2004, Chris McDonough wrote: > Great, I'm going to consider that a resounding endorsement and check it > in soon; please do let me know if you see anything odd come up. > > If anyone else has been having issues with the old Transience module, > and would like to provide feedback on the newer implementation, please > get this file: > > http://cvs.zope.org/*checkout*/Products/Transience/Transience.py?rev=1.32.12.2.2.2&only_with_tag=chrism-sessiongeddon > > ... and temporarily replace Zope's lib/python/Transience/Transience.py > with this newer version to help test it out, and report back the results > here. > > Thanks! > > - C > > > On Wed, 2004-03-03 at 02:14, [EMAIL PROTECTED] wrote: > > Hi Chris, > > > > Until now, we did not got any errors with new Transience.py :) It just > > works, no problems found under high load. > > > > Alex > > > > On Mon, 1 Mar 2004, Chris McDonough wrote: > > > > > > I installed new Transience.py. During my little test it works fine. > > > > But real test will be on Monday when students start logging in as complete > > > > classes, sometimes there are hundreds of them logging on simultaneously, > > > > so we will see. > > > > > > Any news? ;-) > > > > > > > > > > > > > -- > > Alex V. Koval > > http://www.halogen-dg.com/ > > http://www.zwarehouse.org/ > > > > > > ___ > > 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 ) > > -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/ ___ 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 )
