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.


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

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to