Please vote about conflict errors logging
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
1. Do you want these ConflictErrors retried logs to be at level:
INFO
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged?
no traceback
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level:
ERROR jens
Here's my own vote :)
1. Do you want these ConflictErrors retried logs to be at level:
BLATHER
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged?
No, without traceback
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level:
ERROR Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Dec 2, 2005, at 5:00 PM, Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
INFO or BLATHER
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
Traceback if at BLATHER, no traceback if at INFO.
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
ERROR
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
I'll wait until Wednesday morning to collect results.
Thanks, Florent
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.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 )
1. INFO 2. Yes, with traceback (necessary as these are heissenevents) 3. ERROR 4. don't care -- we can adapt Thanks Florent for taking the lead on this. I think it's a great help. On Fri, 2 Dec 2005, Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
I'll wait until Wednesday morning to collect results.
Thanks, Florent
--
Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times)
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
Full traceback, since we're in BLATHER mode
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
ERROR /JM
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
I'll wait until Wednesday morning to collect results.
Thanks, Florent
Jean-Marc Orliaguet wrote:
BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times)
That's because they excluded any useful information before. The implementation I've put in tells you, at info level, what error actually occurred, what object it occurred on, how many conflicts occurred since server start and how many of those were resolved. It's compact and informative. I'd suggest anyone who's voting for blather should actually check out the trunk and try the functional test I put in to see the new code in action... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jean-Marc Orliaguet wrote at 2005-12-2 23:57 +0100:
... on what level to report retried ConflictError ... BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times)
That's because the generated messages *were* uninformative. You can see the critical spots (the objects causing lots of conflicts) easily with sane log messages. -- Dieter
Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-2 23:57 +0100:
... on what level to report retried ConflictError ... BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times)
That's because the generated messages *were* uninformative.
You can see the critical spots (the objects causing lots of conflicts) easily with sane log messages.
In my case it's mostly filesystem-based resources (css files, or images) accessed in read mode (zope-2.8.4). But the information no matter where it comes from has very little value compared to other messages in the log file, because these are completely predictable. In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur "by design". regards /JM
Jean-Marc Orliaguet wrote:
In my case it's mostly filesystem-based resources (css files, or images) accessed in read mode (zope-2.8.4). But the information no matter where it comes from has very little value compared to other messages in the log file, because these are completely predictable.
That's your judgement. Many of us feel differently.
In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur "by design".
...well, by the design of your app, yes. If you're getting more than a few, you really need to reconsider your design. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100:
... In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur "by design".
This argument is not convincing: In a similar way, I could argue that "MemoryError"s are there by design. While it is true that *occational* "ConflictError"s are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors. Obviously, a "ConflictError" is far less important than a "MemoryError", but a higher rate of conflicts should be analysed and if possible avoided. The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late. -- Dieter
Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100:
... In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur "by design".
This argument is not convincing:
In a similar way, I could argue that "MemoryError"s are there by design.
While it is true that *occational* "ConflictError"s are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors.
Obviously, a "ConflictError" is far less important than a "MemoryError", but a higher rate of conflicts should be analysed and if possible avoided.
The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late.
But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file: INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already) Similarly if the number of cache objects is too low, the application will run slowly, do you want to see: INFO: 1000 objects loaded into the cache in the last 5 minutes So why not instead create a product that logs occasional conflict errors? there is already in the ZMI in the database management screen some information about cached objects- Why not add the information that you are looking for there instead? /JM
Jean-Marc Orliaguet wrote:
But aren't you looking for some sort of application profiler?
The point is that you need information to build a profile...
sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too,
Indeed!
still you wouldn't want to see in the log file:
INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already)
Well, yes, you do, but maybe not so verbosely ;-) We have Apache log the time to serve in microseconds for every single request, for later analysis. If you like, I'm happy to add a binary column to Z2.log ;-)
Similarly if the number of cache objects is too low, the application will run slowly,
Well, I don't know if you or I understand zodb's caching to know what to log...
do you want to see:
INFO: 1000 objects loaded into the cache in the last 5 minutes
...but yeah, if you could quantify that having 1000 objects loaded made a significant difference to the perfomance of the request where that was logged, then I'd be all for adding it...
So why not instead create a product that logs occasional conflict errors?
Because it's a lot more work than leaving it like it is but with improved inforamtion, which, from the vote, is going to keep the most people happy anyway ;-)
there is already in the ZMI in the database management screen some information about cached objects- Why not add the information that you are looking for there instead?
That's another possibility, are you volunteering to code it though? ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100:
... But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file:
You err: I do want to see them in the logfile and I stole Florents idea to use "threadframe" (in his "DeadlockDebugger") to include a traceback for long running requests in the logfile. This way, it is easy not only to identify long running requests but also to get hints where they are spending their time... You will not believe how fast this has eliminated our remaining long running requests and especially to track down a non deterministic rarely occuring apparent deadlock situation... Thus, I can *very* strongly recommend to include such logging entries :-)
INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already)
I agree with you about such stupid log entries. And your argument also holds for the stupid "ConflictError" log entries that Zope used to emit. But, we use our own Zope. And our Zope learned very early to emit informative "ConflictError" log entries -- those that show *which* object caused the "ConflictError". These log entries gave valuable hints on how to improve our application. It is this experience that lets me argue for INFO level "ConflictError" log entries. By the way, I can be quite calm: whatever the Zope community might decide: our Zope will continue to log "ConflictError" messages at INFO level because we are interested to get early indications that potential problems crept into our application... -- Dieter
Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100:
... But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file:
You err: I do want to see them in the logfile and I stole Florents idea to use "threadframe" (in his "DeadlockDebugger") to include a traceback for long running requests in the logfile. This way, it is easy not only to identify long running requests but also to get hints where they are spending their time...
You will not believe how fast this has eliminated our remaining long running requests and especially to track down a non deterministic rarely occuring apparent deadlock situation...
Thus, I can *very* strongly recommend to include such logging entries :-)
Absolutely, this is called "debugging an application" (=> DEBUG, TRACE). Our sysadms are not really interested in this kind of info. They want to know if some action should be taken or not and messages such as these are misleading. If Florent mentionned that customers are calling to ask, obviously there is a problem.
INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already)
I agree with you about such stupid log entries. And your argument also holds for the stupid "ConflictError" log entries that Zope used to emit.
But, we use our own Zope. And our Zope learned very early to emit informative "ConflictError" log entries -- those that show *which* object caused the "ConflictError". These log entries gave valuable hints on how to improve our application.
Sure, but I think that you are both developer and sysadm at the same time. This is not the case everywhere.
It is this experience that lets me argue for INFO level "ConflictError" log entries.
By the way, I can be quite calm: whatever the Zope community might decide: our Zope will continue to log "ConflictError" messages at INFO level because we are interested to get early indications that potential problems crept into our application...
Absolutely, I don't deny it. This is valuable information for developers. /JM
Jean-Marc Orliaguet wrote at 2005-12-6 21:45 +0100:
...
You err: I do want to see them in the logfile and I stole Florents idea to use "threadframe" (in his "DeadlockDebugger") to include a traceback for long running requests in the logfile. This way, it is easy not only to identify long running requests but also to get hints where they are spending their time...
You will not believe how fast this has eliminated our remaining long running requests and especially to track down a non deterministic rarely occuring apparent deadlock situation...
Thus, I can *very* strongly recommend to include such logging entries :-)
Absolutely, this is called "debugging an application" (=> DEBUG, TRACE). Our sysadms are not really interested in this kind of info.
Ours are -- especially to hunt down non-deterministic problems that actually are mail server problems (the above mentioned "apparent deadlock" was caused by a mail server occationally not responding for many minutes).
They want to know if some action should be taken or not and messages such as these are misleading.
Long running requests (and a high rate of "ConflictError"s) *ARE* instances when "some action should be taken" -- probably to contact the vendor/developper.
...
But, we use our own Zope. And our Zope learned very early to emit informative "ConflictError" log entries -- those that show *which* object caused the "ConflictError". These log entries gave valuable hints on how to improve our application.
Sure, but I think that you are both developer and sysadm at the same time. This is not the case everywhere.
True. But "ConflictError"s occur non-deterministically. Whenever, you are faced with non-deterministical problems, you are quite happy when the true operational system provides enough information to guide the analysis -- because it is so difficult to reproduce the behaviour in a development environment. -- Dieter
Jean-Marc Orliaguet wrote:
Absolutely, this is called "debugging an application" (=> DEBUG, TRACE).
Well, I call BS on this ;-) Things like ConflictErrors and slow-running requests are not something you often find out about during application development. They emerge once the load ramps up and are something any responsible admin of a large production system will want to keep a continuing eye on. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Dieter Maurer wrote:
In a similar way, I could argue that "MemoryError"s are there by design.
While it is true that *occational* "ConflictError"s are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors.
Obviously, a "ConflictError" is far less important than a "MemoryError", but a higher rate of conflicts should be analysed and if possible avoided.
The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late.
It's not often you get my and Dieter agreeing, but a huge +1 to all of this from me! Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
BLATHER
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
Yes, with traceback
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
ERROR
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
Make it the same. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkQ+++gerLs4ltQ4RAhDrAJ9pjTXb9F6bEoZGQ1xTA2lyI47knQCgiXWK 8blEg0KiwVIIKlt95gK9CPg= =JUyS -----END PGP SIGNATURE-----
Florent Guillaume wrote:
1. Do you want these ConflictErrors retried logs to be at level: - INFO
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - No, without traceback
The actual traceback for any conflict error is pretty useless, since it comes from one of very few places inside zodb
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR
...ie: handled in the same way as any other user-visible error: standard_error_message and error_log. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Florent Guillaume wrote at 2005-12-2 23:00 +0100:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
INFO
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
No traceback, as it usually will come from commit code and not really contain useful information.
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
They should be treated as any other exception seen by the user: They should be routed via "error_log" and "standard_error_message"; they should not cause a special log entry (they are not more dangerous than other exceptions seen by the user). I think your vote might be more interesting for Zope users rather than Zope developers. -- Dieter
Florent Guillaume wrote at 2005-12-2 23:00 +0100:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
INFO (i *really* want to know, if there are lots of conflict errors)
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
No traceback (as Dieter has pointed out, they contain no useful information)
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
Like any other exception seen by the user Thanks! \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
On Fri, 2005-12-02 at 23:00 +0100, Florent Guillaume wrote:
1. Do you want these ConflictErrors retried logs to be at level: - INFO INFO - BLATHER - DEBUG - not logged - other
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback No Traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other Error
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
I'll wait until Wednesday morning to collect results.
Thanks, Florent
Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
BLATHER.
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
with traceback because of the BLATHER mode above.
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
ERROR
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
Of course the same... J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDlNhcGhoG8MxZ/pIRAsg4AJkBPnW4zGrl4GdZxEXXEZCpwcCdswCfU3hE 41XwD/GgOGRNAEC0nYh7lKM= =qNsx -----END PGP SIGNATURE-----
1. Do you want these ConflictErrors retried logs to be at level:
INFO 2. In addition, please specify if you feel those retried
ConflictErrors should have their full traceback logged?
no, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be
retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level:
ERROR
How about adding a URL to the logged message? Something like "See http://zope.org/ConflictError" detailing the difference between a retried and unresovled ConflictErrors and how to recognise them in the event.log.
Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR So here's what I'll do: 1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO. 2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3. 3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log. So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. Florent Florent Guillaume wrote:
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher.
1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other
2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback
3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other
(Also, if you feel the logging should be different between 2.8 and 2.9, please say so.)
I'll wait until Wednesday morning to collect results.
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Fri, Dec 09, 2005 at 03:45:18PM +0100, Florent Guillaume wrote:
So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off.
+100 -- Paul Winkler http://www.slinkp.com
Florent Guillaume wrote:
Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR
1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO.
As an idea, make your zope.conf key be of the same type as the "level" parameter in the eventlog section, that way, you should be able to change the code to be: logger.log(whatever_your_zconfig_option_is,...whatever I used...) ...making it even more flexible at no extra cost. Some people (maybe me ;-) might even like this stuff logged at logging.error so I get a MailingLogger entry _whenever_ a ConflictError is logged, not just when a user sees it. (this is because I have a good idea that ConflictErrors due to silly use of the temp_folder in the largest of the projects I'm currently working on is a major source of poor performance) Also, in case you don't manage the above, please use logging.debug, not BLATHER, since I'll be eradicating that silly name as part of my work to deprecate zLOG...
2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3.
Indeed, and it's still just as useless there ;-)
3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log.
Yup :-)
So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off.
+lotz :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Guillaume wrote:
Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR
So here's what I'll do:
1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO.
OK, I can live with that. I was going to suggest a config option, but defaulted the other way.
2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3.
3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log.
So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off.
+1 to that (as long as we leave Unauthorized, NotFound, and Redirect excluded by default). Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmfRJ+gerLs4ltQ4RAnRoAKCiWk45LPc55C71Uuji6qGHgfEnfgCfbHvr fpKYRC+teAopydRnW6esJmA= =IR1c -----END PGP SIGNATURE-----
participants (14)
-
Andrew Sawyers -
Chris McDonough -
Chris Withers -
Dennis Allison -
Dieter Maurer -
Florent Guillaume -
Jean-Marc Orliaguet -
Jens Vagelpohl -
Julien Anguenot -
M. Krainer -
Michael Dunstan -
Paul Winkler -
Tres Seaver -
Willi Langenberger