[ZODB-Dev] POSKeyError with Zope 2.7.2, suddenly appeared, thendisappeared...

Tim Peters tim at zope.com
Mon Feb 7 15:46:37 EST 2005


[Jens Vagelpohl]
>> That's normal, but it gets logged at an inappropriate log level, that's
>> all. This should be logged at BLATHER, really.

[Chris Withers]
> Heh, that won't even be a log level for much more, hopefully ;-)

When mass conversion to Python's logging module was done, it doesn't look
like anyone addressed this per se.  Instead, in ZODB, new (relative to what
comes built in) BLATHER and TRACE levels were added to Python's logging
module (the logging module has an API for adding as many logging levels as
you can dream up).  In ZODB 3.3, this is set up in the teensy
ZODB/loglevels.py.

> debug should be right?

I can't agree that info level was inappropriate here, at least not without a
lot more thought than I can give to it now.  A problem with ZEO is that
people normally want a way to tell that ZEO is still _alive_ in info-level
logs.  Logging info about transaction-lock activity is one natural way to do
that (if you're doing transactions over ZEO, but not seeing those msgs, you
can deduce that ZEO is dead or deadlocked or something; and looking then at
the last lock activity logged can be a good clue about how things got
hosed).

In any case, it doesn't make much sense to be _concerned_ about a message
that logs itself at info level.  If the code thought it was a bug condition,
it would have logged it at warn/problem, error, or fatal/critical level.



More information about the ZODB-Dev mailing list