[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug review of the week

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Fri, 10 Jan 2020 00:36:48 -0500

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.)


Received on 2020-01-10 06:37:09 CET

This is an archived mail posted to the Subversion Dev mailing list.