[ZCM] [ZC] 1805/ 3 Resolve "Logging after ConflictError Retries"

Collector: Zope Bugs, Features, and Patches ... zope-coders-admin at zope.org
Thu Dec 1 13:48:27 EST 2005


Issue #1805 Update (Resolve) "Logging after ConflictError Retries"
 Status Resolved, Zope/bug low
To followup, visit:
  http://www.zope.org/Collectors/Zope/1805

==============================================================
= Resolve - Entry #3 by efge on Dec 1, 2005 1:48 pm

 Status: Pending => Resolved

Fixed in 2.9 and trunk.

http://svn.zope.org/?rev=40454&view=rev

________________________________________
= Comment - Entry #2 by MalcolmCleaton on Jun 10, 2005 6:10 am

Dieter Maurer suggests a better fix for (1):

The fix is (almost surely) to replace in ".../Zope/App/startup.py":

   if t is ZPublisher.Retry: v.reraise()

by

   if t is ZPublisher.Retry: t, v, traceback = v._args

I've moved (2) to a new issue (1806) due to the general foolishness of having one issue for two bugs.

Thanks,
Malcolm.


________________________________________
= Request - Entry #1 by Anonymous User on Jun 9, 2005 5:09 am

After a ConflictError causes a request to be retried, a few things go a bit wrong with error handling and logging in the Zope server.

1. If the request is abandoned after repeated ConflictErrors, no error at all appears in the error log.

The following change to Zope/App/startup.py appears to fix this, although I'm not sufficiently experienced in the depths of Zope to be sure there are no downsides:

162,163c162
<                 if REQUEST.supports_retry():
<                     raise ZPublisher.Retry(t, v, traceback)
---
>                 raise ZPublisher.Retry(t, v, traceback)

If a Retry error is raised again here even though we don't support any more retries, the ZServer calls the exception hook again with the Retry error, we throw it again and the error logging is missed. Simply not raising the Retry error again once we don't support any more retries means we fall through to the rest of the exception handling hook, and the ConflictError itself is logged, which I think is right.


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.

I can think of a few things which might fix this, but they all feel like they might also break many other subtle things, and I've got The Fear; can somebody more experienced in the core comment on the Right Way?

Thanks,
Malcolm.



==============================================================



More information about the Zope-Collector-Monitor mailing list