Re: [Zope-dev] Re: Logging of ConflictError
Sidnei da Silva wrote: On Dec 2, 2005, at 3:51 PM, Chris Withers wrote: Sidnei da Silva wrote: I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: Yes, that bit is simple. But in 2.8.something and above, the eventlog is plugged in as a root logger, meaning you can't get anything logged that doesn't go to it. Who made this change and why? Yes you can. Just set 'propagate' to a non-true value. Can you be a bit more descriptive? OS thisa zope.conf option? an option to the logger call? etc? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
On Sat, Dec 03, 2005 at 07:51:28PM +, Chris Withers wrote: | Sidnei da Silva wrote: | | On Dec 2, 2005, at 3:51 PM, Chris Withers wrote: | | Sidnei da Silva wrote: | | I was looking at the same issue yesterday, and it's really a trivial | change. Need to add a 'multisection' to zopeschema.xml that allows | multiple 'logger' type entries. Then you can just do something like: | | | Yes, that bit is simple. But in 2.8.something and above, the eventlog | is plugged in as a root logger, meaning you can't get anything logged | that doesn't go to it. Who made this change and why? | | Yes you can. Just set 'propagate' to a non-true value. | | Can you be a bit more descriptive? OS thisa zope.conf option? an option | to the logger call? etc? Heard of grep? *wink* From ZConfig/components/logger/logger.xml key name=propagate datatype=boolean default=true description Indicates whether events that reach this logger should be propogated toward the root of the logger hierarchy. If true (the default), events will be passed to the logger's parent after being handled. If false, events will be handled and the parent will not be informed. There is not a way to control propogation by the severity of the event. /description /key -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
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@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 ) ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
On Fri, Dec 02, 2005 at 03:09:40PM +, Chris Withers wrote: | 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. I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: logger this.that.the_other level BLATHER propagate 0 # if you don't want it to end up in error.log logfile level BLATHER path $INSTANCE/log/theother.log /logfile /logger I haven't gotten around to make the proposal for change, but since you did, here's my 2 cents. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
Sidnei da Silva wrote: I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: Yes, that bit is simple. But in 2.8.something and above, the eventlog is plugged in as a root logger, meaning you can't get anything logged that doesn't go to it. Who made this change and why? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
On Dec 2, 2005, at 3:51 PM, Chris Withers wrote: Sidnei da Silva wrote: I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: Yes, that bit is simple. But in 2.8.something and above, the eventlog is plugged in as a root logger, meaning you can't get anything logged that doesn't go to it. Who made this change and why? Yes you can. Just set 'propagate' to a non-true value. -- Sidnei da Silva Enfold Systems, LLC http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging of ConflictError
On Thu, Dec 01, 2005 at 02:03:51PM -0500, Tres Seaver wrote: Do people want this also for 2.8? Note that it changes the log format, so may break third party tools that parse logs. +1. +1 from me too, the added information is worth potential tool breakage IMO. Just put an obvious note in CHANGES.txt as usual. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@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 )
Re: [Zope-dev] Re: Logging after ConflictError Retries
Malcolm Cleaton wrote at 2005-6-10 11:00 +0100: ... 2. If there is at least one ConflictError and then the request finishes with an error (either more ConflictErrors or something else), the Z2 log shows the request as having been answered with status 200, although actually a status 500 error response has been served. I've managed to work out what's causing this, but fixing may be more fiddly. What happens is, once the request is abandoned because of the error, when control comes back to publish_module_standard in Publish.py, response.exception() is called on the original response, not on the latest retry. Then, when HTTPResponse _finish() is called, it traces down to the latest retry to find the status code for the logging, which is now the wrong one. This should only happen when publish itself raises an exception. Usually, publish should *NOT* raise an exception, when the request fails (although exceeding the maximal number of retries may cause this). My debugger indicates that publish in fact does raise an exception, whether or not retries are in play. zpublisher_exception_hook calls raise_standardErrorMessage, which raises, and this exception propagates all the way to the catch in publish_module_standard. You and your debugger are right! I do not understand why raise_standardErrorMessage needs to raise an exception rather than just set up the response -- but it indeed raise an exception... Apparently, Retry must be carefully rethought. Please file a critical bug report... -- Dieter ___ Zope-Dev maillist - Zope-Dev@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 )
