On Thu, Jan 9, 2020 at 7:34 AM Branko Čibej <brane_at_apache.org> wrote:
> On 09.01.2020 13:28, Nathan Hartman wrote:
>
> On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
> wrote:
>
>> Nathan Hartman <hartman.nathan_at_gmail.com> writes:
>>
>> > SVN-4588 "Item index too large in revision" is marked as Unresolved, but
>> > from my reading of all the comments, it seems the root cause of the
>> problem
>> > was not restarting httpd after dumping and loading, leaving stale
>> > information in cache.
>> >
>> > The last comment mentions a similar report on Stack Overflow. That one
>> > magically fixed itself by rebooting. See:
>> >
>> https://stackoverflow.com/questions/33904618/how-to-increase-l2p-page-size/33938501
>> >
>> > So... is there anything else to do for this one?
>>
>> There is an option of making the filesystem instance IDs part of the cache
>> keys. Doing so would fix the case described in SVN-4588 and allow other
>> operations that happen through the command-line tools, such as "svnadmin
>> hotcopy" to work properly without the server restart.
>>
>> See
>> https://lists.apache.org/thread.html/6db0186496a46c9823a752b377e369eb4361c8a42e62fc7e601453c6%401440460036%40%3Cdev.subversion.apache.org%3E
>
>
> My reading of the above left me confused. On one hand, it sounds like that
> should greatly reduce the probability of this problem. OTOH it seems like
> some people had concerns: Apparently not including the instance ID in the
> cache keys helps to "fail early"?
>
> So my questions:
>
> 1. Are there any downsides to doing it?
>
> 2. Since it reduces, but does not completely eliminate, the probability of
> this issue, are there any additional steps we could take? For example is it
> possible to detect a running svnserve/httpd and warn about it?
>
>
> You can't reliably do that. And yes, the reason for concern is precisely
> that the "fix" doesn't eliminate the problem, it only makes it less likely
> to show up, thus making it harder to reproduce and diagnose. That's a
> pretty huge downside compared to documenting that servers need to be
> restarted in some cases.
>
> Of course, writing a proper cross-process cache that's not a bolt-on
> afterthought would be even better ...
>
Okay so this is what I suggest:
Closing this issue (4588), and creating a new issue with a proper title and
description of the root problem, referring to 4588 as an example of how the
problem manifests, and to the archived mailing list discussions.
(Unless there is already a suitable issue, in which case, obviously, we'd
use it instead.)
Thoughts?
Nathan
Received on 2020-01-10 06:37:09 CET