You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2020/01/08 11:22:39 UTC
Bug review of the week
Hey Nathan, time to propose another bug review of the week?
- Julian
Re: Bug review of the week
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jan 10, 2020 at 12:36 AM Nathan Hartman
<ha...@gmail.com> wrote:
> 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.
Ping...
I think SVN-4588 should be closed. The original problem resolved
itself. (Any objections?)
My question is, should we:
(A) Create a new issue that describes the root cause; it would refer
to SVN-4588 and mailing list discussions for context.
or
(B) Not file a new issue; close SVN-4588 and declare that this is not
a problem as changing a repository while the server processes are
running is an unsupported use case.
Thanks,
Nathan
Re: Bug review of the week
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jan 9, 2020 at 7:34 AM Branko Čibej <br...@apache.org> wrote:
> On 09.01.2020 13:28, Nathan Hartman wrote:
>
> On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov <ev...@visualsvn.com>
> wrote:
>
>> Nathan Hartman <ha...@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
Re: Bug review of the week
Posted by Branko Čibej <br...@apache.org>.
On 09.01.2020 13:28, Nathan Hartman wrote:
> On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov
> <evgeny.kotkov@visualsvn.com <ma...@visualsvn.com>> wrote:
>
> Nathan Hartman <hartman.nathan@gmail.com
> <ma...@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
Re: Bug review of the week
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov <ev...@visualsvn.com>
wrote:
> Nathan Hartman <ha...@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?
Thanks,
Nathan
<https://lists.apache.org/thread.html/6db0186496a46c9823a752b377e369eb4361c8a42e62fc7e601453c6%401440460036%40%3Cdev.subversion.apache.org%3E>
Re: Bug review of the week
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Nathan Hartman <ha...@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
Thanks,
Evgeny Kotkov
Re: Bug review of the week
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/SVN-4588
>
> 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?
That's funny... I was just reading that one myself. It does look like,
while there are potential follow-up avenues that Stefan2 mentioned in
the last few comments, basically the issue is resolved and should be closed.
- Julian
Re: Bug review of the week
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jan 8, 2020 at 6:22 AM Julian Foad <ju...@apache.org> wrote:
> Hey Nathan, time to propose another bug review of the week?
Hi Julian,
Thanks for the nudge. :-)
https://issues.apache.org/jira/plugins/servlet/mobile#issue/SVN-4588
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?
Cheers,
Nathan