[Zope-dev] Re: Logging of ConflictError

[Chris McDonough]

I initially gave Florent's proposal a +1 because frankly I'm kinda  
sick of answering people's questions about conflict "errors" (this  
deserves some treatment in docs actually).  But I do agree that it is  
useful to be able to see conflict errors in non-blather logs when you  
*do* know what they mean; I was just going to patch Zope myself  
locally to be able to see them after Florent applied his "for the  
masses" patch.

If other people like Chris feel strongly about displaying them, I'm  
not going to complain much.  Sometimes it's useful for people who  
*don't* know what they mean to see them so that when their myisam  
tables have three copies of a row or their mailhost is sending two  
emails instead of one, that we can ask them to go look at their logs  
and search for a conflict error.  The answer is always the same.. use  
a transactional doodad, but it's useful to be able to "get there"  
with them.

IOW, either way is fine by me.

On Dec 2, 2005, at 10:09 AM, Chris Withers wrote:

> Tres Seaver wrote:
>>> I strenuously object to you overwriting without consultation code  
>>> I just checked in and that was approved by at least 3 people.
>>>
>>> And I'm totally -1 on any logging at level INFO or above about  
>>> retriable conflict errors.
>> Likewise -1.  A successfully retried conflict should not clutter  
>> up the log.
>
> Huh? How is it cluttering up the log? At INFO level, I assert that  
> if you see enough of these to judge them "clutter", you really  
> ought to have a look at where they're coming from and solve the  
> performance problem they'll be causing...
>
>>> Not so. If I'm getting 1,000 resolved conflict errors a day, that  
>>> can
>>> be a big performance hit, and there are those of us who have hard
>>> performance targets to meet ;-) Turning on debug logging is, in  
>>> itself,
>>> a performance hit, so I don't want to have to do that on a  
>>> production
>>> service where I want to observe the number of conflict errors  
>>> occurring
>>> over a long period of time, like, say, a month.
>> You need to plan to set up and *additional* logging handler for this,
>
> OK, first point, Florent's change was one that changed existing  
> functionality that I, for one, was relying on. Should that really  
> be happening on the 2.8 branch at the very least?
>
>> which logs *only* conflict errors at *whatever* level, rather than
>> requiring everybody else to live with output they don't need or  
>> want to
>> see.
>
> I still assert that the belief it is information you shouldn't want  
> to see is incorrect.
>
>> I figured out how to do this once, long ago, to surface some
>> obscure BLATHER-level notification;  given your familiarity with the
>> logging module, it should be a snap for you. ;)
>
> Yes, unfortunately it's this familiarity that means I can point out  
> the problem. At some point in 2.8's development, someone made the  
> bright idea of having the event log be the root python logger.  
> While I liked this in theory, in practice it means you can't set up  
> seperate logs in the way you describe, since everything ends up  
> getting fired at the event log anyway :-(
>
> Then there's the issue that zope.conf doesn't support the  
> configuration of additional loggers, when it really should ;-)
>
> I'm happy to try and find time to work on the latter issue, if  
> whoever made the change that resulted in the former 'fesses up and  
> explains why the change was made.
>
> In either case, I don't think it's fair to require this problem be  
> solved in order for necessary conflict error logging to be resumed :-(
>
> Chris
>
> -- 
> Simplistix - Content Management, Zope & Python Consulting
>            - http://www.simplistix.co.uk
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> 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 )
>