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 >>>wrong one. >> >> 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... -- Dieter _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
