On Thu, Jan 9, 2020 at 7:34 AM Branko Čibej <[email protected]> wrote:
> On 09.01.2020 13:28, Nathan Hartman wrote: > > On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov <[email protected]> > wrote: > >> Nathan Hartman <[email protected]> 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
