Re: Handling assertions and malfunctions in mod_dav_svn

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 API call into it, thus causing all svn threads (that use it) to fail without affecting non-svn threads.

> However, neither option is necessarily safe:

Reasoning about 'safety' is difficult. Firstly, when an assertion has failed, in general we don't know that data hasn't already been lost. This matters when we qualitatively assess actions according to their likelihood of further loss, because "this action won't, in itself, lose data" is qualitatively closer to "data may have been lost" than to "no data has been lost".

> - The first might cause data loss if the assertion was ultimately caused
>   by, say, faulty hardware.  (If we have faulty hardware, aborting could
>   actually be the best option, since it prevents non-mod_dav_svn threads
>   from experiencing data losses.)

This sounds like faulty reasoning. Aborting would indeed prevent the particular threads that are running *at the time* from losing data *actively* (but not through failure to complete an action), in the future (but they may already have lost data due to the same ultimate cause). That doesn't mean data loss is overall less likely. A lot of other factors are involved. A new process will eventually replace the killed threads and try again to do whatever they were doing. The whole course of the server's execution history will proceed in a new direction, possibly with less data loss overall, possibly with more.

> - The second might lead to unacceptable performance degradation.
>
> - The third will take down non-mod_dav_svn threads too, resulting in
>   denial of service for the requests those threads were handling.
>
> How do we choose between three risks?  Is this perhaps a place where
> it's justified to create a knob for the admin to set according to her
> own risk analysis?

It's only worth having a knob if we first do enough risk analysis ourselves to determine that different settings of the knob will have real value to different user groups.

- Julian

> ---
[...]
Received on 2015-02-24 11:01:01 CET