Malcolm Cleaton wrote at 2005-6-9 10:13 +0100:
>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.
Right: please file a bug report.
The fix is (almost surely) to replace in ".../Zope/App/startup.py":
if t is ZPublisher.Retry: v.reraise()
if t is ZPublisher.Retry: t, v, traceback = v._args
>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
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).
Nevertheless, the mixed use of "response" and "request.response"
looks wrong. Almost surely, "request.response" should
get the value of "response" when "publish" succeeds and
both are different.
Thus I expect, we should have:
response = publish(...)
request.response = response
Please file two bug reports for the problems you discovered...
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -