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