Malcolm Cleaton wrote at 2005-6-10 11:00 +0100:
>>>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).
>My debugger indicates that publish in fact does raise an exception,
>whether or not retries are in play. zpublisher_exception_hook calls
>raise_standardErrorMessage, which raises, and this exception propagates
>all the way to the catch in publish_module_standard.
You and your debugger are right!
I do not understand why "raise_standardErrorMessage"
needs to raise an exception rather than just set up
the response -- but it indeed raise an exception...
Apparently, "Retry" must be carefully rethought.
Please file a critical bug report...
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -