On Tue, Feb 17, 2015 at 3:44 AM, Ben Reser wrote:
>
> I think a potentially bigger problem might be what to do about cache state.
> Cache reads are obviously not a problem. Theoretically, a cache write
> shouldn't happen until after a repository modification so that if we fail
> the
> repository
Daniel Shahaf wrote on 2015-02-17:
> What can we do if an assertion fails inside the cache implementation?
>
> I see three options: log it and continue; continue with cache disabled;
> abort.
There are other options. One is:
* Let the cache return an error for this API call and every subsequent
Evgeny Kotkov wrote on Tue, Feb 17, 2015 at 20:44:29 +0300:
> - We attempt to solve "B) Taking down other threads" in 1.10 by carefully
> examining the calling sites, how the caching behaves, etc., and aim towards
> a guarantee that nothing will break with a non-abortive malfunction handler.
>
On 2/17/15 12:01 PM, Evgeny Kotkov wrote:
> Ben Reser writes:
>
>> +1 except for the mod_dav_svn: prefix in the log output. httpd should be
>> adding that for you with APLOG_MARK.
>
> I committed the patch in r1660480 and chose to keep the "mod_dav_svn:" prefix
> for two reasons:
>
> - Other m
On 17.02.2015 19:20, Ben Reser wrote:
> +1 except for the mod_dav_svn: prefix in the log output. httpd should
> be adding that for you with APLOG_MARK.
There's currently one ap_log_error call in mod_dav_svn, and has
"mod_dav_svn:" in the error string. If this is indeed duplicate, we
should fix al
Ben Reser writes:
> +1 except for the mod_dav_svn: prefix in the log output. httpd should be
> adding that for you with APLOG_MARK.
I committed the patch in r1660480 and chose to keep the "mod_dav_svn:" prefix
for two reasons:
- Other messages nearby use the same prefix.
- If I am not mistake
On 2/17/15 9:44 AM, Evgeny Kotkov wrote:
> I was thinking that the runtime option could be useful, because the desired
> behavior might depend on the MPM being used. With non-threaded pre-forking
> servers, problems with a single request wouldn't affect other requests [1].
> Threaded servers, howe
On 17 February 2015 at 20:44, Evgeny Kotkov wrote:
> Ben Reser writes:
>
>> If we're going to make this behavior optional I'd rather it just be a compile
>> time directive rather than a run time directive. Most users aren't going to
>> understand what this means and I can't imagine there would b
On 17.02.2015 18:44, Evgeny Kotkov wrote:
> Ben Reser writes:
>
>> If we're going to make this behavior optional I'd rather it just be a compile
>> time directive rather than a run time directive. Most users aren't going to
>> understand what this means and I can't imagine there would be very man
Ben Reser writes:
> If we're going to make this behavior optional I'd rather it just be a compile
> time directive rather than a run time directive. Most users aren't going to
> understand what this means and I can't imagine there would be very many
> scenarios where run time configuration is de
On 2/16/15 5:21 PM, Evgeny Kotkov wrote:
> 2) Install a non-abortive mod_dav_svn malfunction handler, which would log the
>malfunction details using ap_log_error() and return SVN_ERR_ASSERTION_FAIL
>when CAN_RETURN = TRUE. This option is similiar to the current behavior of
>a non-defau
Subversion's mod_dav_svn module currently uses a default malfunction handler,
svn_error_abort_on_malfunction(). This means that SVN_ERR_MALFUNCTION() or
failed SVN_ERR_ASSERT() statements output the malfunction details to STDERR
and abort() the current process. Doing so within an Apache module —
12 matches
Mail list logo
