[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: Branko Čibej <brane_at_apache.org>
Date: Thu, 9 Jan 2020 13:33:57 +0100

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 <mailto:evgeny.kotkov_at_visualsvn.com>> wrote:
>
> Nathan Hartman <hartman.nathan_at_gmail.com
> <mailto: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 ...

-- Brane
Received on 2020-01-09 13:33:59 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.