Dieter Maurer wrote:
-self._log.error(msg)
+self._log.error(msg,exc_info=True)
raise ConnectionStateError(msg)
I mind -- the change is stupid:
Because you are not in an exception handler, "exc_info=True"
cannot provide meaningful information -- there is
[Tim]
...
>> BTW, I haven't seen a traceback associated with your "shouldn't load
>> state" problems. Do any exist? (I understand they may not be logged,
>> I'm wondering if you can see them from the ZMI. If it _is_
>> unintentional caching, a traceback could be invaluable.)
[Chris Withers]
> I
Chris Withers wrote at 2005-10-21 15:28 +0100:
> ...
>Do you mind if I apply the following patch to the ZODB trunk?
>
>Index: Connection.py
>===
>--- Connection.py (revision 39510)
>+++ Connection.py (working copy)
>@@ -725
Tim Peters wrote:
If a client restarted during the day, wouldn't you find evidence of that in
your logs?
Yep...
This is all there is to it, where Data.fs has a single large OOBTree
attached as to the root under key "tree":
st = ZODB.FileStorage.FileStorage('Data.fs')
db = ZODB.DB(st)
cn =
[Chris Withers]
> ...
> Hmm.. well, I guess the clients could have restarted during the day and
> so maybe it is a startup race?
If a client restarted during the day, wouldn't you find evidence of that in
your logs?
...
That one comes out of Connection.setstate(), and appears to mean what
>
[Chris Withers]
>>> First question, would you mind if I added oid_unrepr to ZODB.utils? I
[Dieter Maurer]
>> Why do you not like "p64" (which is already there)?
[Chris]
> If that's the case, then great :-)
>
> I was just asking 'cos I couldn't find he functionality anywhere,
You found ZODB.utils
Dieter Maurer wrote:
First question, would you mind if I added oid_unrepr to ZODB.utils? I
Why do you not like "p64" (which is already there)?
p64(0x)
behaves very similar to
oid_unrepr('0x')
If that's the case, then great :-)
I was just asking 'cos I couldn't find he functionali
Chris Withers wrote at 2005-10-19 13:53 +0100:
> ...
>from binascii import unhexlify
>def oid_unrepr(oidr):
> if oidr.startswith('0x'):
> oidr = oidr[2:]
> h = unhexlify(oidr)
> return '\x00'*(8-len(h))+h
>
>def oidr2obj(app,oidr):
> return app._p_jar[oid_unrepr(oidr)]
>
>Fi
Hi Tim,
Tim Peters wrote:
As before, this "Shouldn't load state ..." error is almost certainly due to
a logic error in some product you're using, or in Zope. Take this message
as meaning exactly what it says: something is trying to work with a
persistent object after the Connection it came fro
Hi Tim,
Thanks for the feedback,
[Chris]
AttributeError: ClientCache instance has no attribute '_get'
Both at random times while the servers are running...
Tim Peters wrote:
Then-- sorry --I don't have a clue. Like I said, I don't see any code
capable of removing a ClientCache's `_get` at
[Chris Withers]
>>> We've been seeing these errors for a while now, but had assumed it was
>>> due to an old Zope version. We've been running 2.7.7 for a week or two
>>> now and we're still seeing these intermittently:
...
>>> AttributeError: ClientCache instance has no attribute '_get'
[Tim Pet
Hey Tim :-)
Tim Peters wrote:
We've been seeing these errors for a while now, but had assumed it was
due to an old Zope version. We've been running 2.7.7 for a week or two
now and we're still seeing these intermittently:
At any particular time(s)? For example, do these (either or both) tend t
[Chris Withers]
> We've been seeing these errors for a while now, but had assumed it was
> due to an old Zope version. We've been running 2.7.7 for a week or two
> now and we're still seeing these intermittently:
At any particular time(s)? For example, do these (either or both) tend to
occur when
Hi All,
We've been seeing these errors for a while now, but had assumed it was
due to an old Zope version. We've been running 2.7.7 for a week or two
now and we're still seeing these intermittently:
ERROR(200) zrpc-conn(C):x.x.x.x: Asynchronous call raised
exception:
Traceback (most rece
14 matches
Mail list logo
