Tim Peters wrote at 2004-2-24 17:30 -0500:
...
I think I'd like to raise an exception when a connection is closed but
changes from that connection are pending in the current transaction.
+1
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
This is what I found in the event.log today:
There was a python.core around 19:33.
2004-02-23T19:33:34 INFO(0) ZServer HTTP server started at Mon Feb 23
19:33:34 2004
Hostname: localhost
Port: 8001
--
2004-02-23T19:33:35 INFO(0) ZCS:21613 ClientStorage (pid=21613) created
Sandor Palfy wrote at 2004-2-24 09:11 -0600:
...
--
2004-02-23T19:34:42 ERROR(200) ZODB A storage error occured during
object abort. This shouldn't happen.
Traceback (most recent call last):
File /zope/zopestable/lib/python/ZODB/Transaction.py, line 401, in
_commit_error
Sandor Palfy wrote at 2004-2-24 09:48 -0600:
I followed Jeremy's instructions to get the trace from python.core.
Here's the script:
...
$ gdb /zope/python23/bin/python ./python.core GNU gdb 4.16.1
Almost surely, your gdb is far too old to analyse the core
of a multi-threaded program (such as
#0 0x6257255 in select_select (self=0x0, args=0x3d641f7c)
at
/usr/local/src/python_release23-maint/Modules/selectmodule.c:171 171
} (gdb) bt #0 0x6257255 in select_select (self=0x0, args=0x3d641f7c)
at
/usr/local/src/python_release23-maint/Modules/selectmodule.c:171
[Dieter Maurer]
[Dieter Maurer]
This means that the current transaction references a connection
that is meanwhile closed.
Some earlier request forgot to commit or abort the transaction;
therefore, the transaction contains still references to the former
connection.
I had to fix product installation code
This is a guess, but perhaps the Catalog is masking some other low-level
error and returning None instead? I'll see if that seems possible from
the code.
Some time ago, I found out that
OFS.Traversable.Traversable.unrestrictedTraverse
catched ConflictError and returned default if a default
On Fri, 20 Feb 2004 22:18:33 +0100
Dieter Maurer [EMAIL PROTECTED] wrote:
Casey Duncan wrote at 2004-2-20 10:53 -0500:
...
This is a guess, but perhaps the Catalog is masking some other
low-level error and returning None instead? I'll see if that seems
possible from the code.
Some time
On Saturday 21 February 2004 06:04, Casey Duncan wrote:
This is indeed possible. getObject swallows all errors and returns None
when one occurs. This would make it return None on busy systems if the
traversal during getObject raised a read ConflictError.
This would indeed result in the
On Fri, 20 Feb 2004 09:47:47 +1100
Richard Jones [EMAIL PROTECTED] wrote:
On Friday 20 February 2004 05:52, Dieter Maurer wrote:
We have a report for Zope 2.7 about an object magically turning
into None (1 or 2 weeks ago).
Sorry, I haven't been following this thread, but I will note that
Casey Duncan wrote at 2004-2-20 10:53 -0500:
...
This is a guess, but perhaps the Catalog is masking some other low-level
error and returning None instead? I'll see if that seems possible from
the code.
Some time ago, I found out that
OFS.Traversable.Traversable.unrestrictedTraverse
catched
11 matches
Mail list logo
