You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2015/03/20 22:44:39 UTC

[jira] [Resolved] (OAK-2404) Provide more information in SegmentNotFoundException

     [ https://issues.apache.org/jira/browse/OAK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig resolved OAK-2404.
--------------------------------
    Resolution: Fixed

Applied the patch at 
* Trunk: http://svn.apache.org/r1668160
* 1.0: http://svn.apache.org/r1668163

Cleaned segments are now logged at INFO level to a separate logger "org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC". Let's see how long it takes until this is called log spam. Depending on such reactions we can the decide how to take this further into better tooling.

> Provide more information in SegmentNotFoundException
> ----------------------------------------------------
>
>                 Key: OAK-2404
>                 URL: https://issues.apache.org/jira/browse/OAK-2404
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: segmentmk
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>              Labels: gc, monitoring
>             Fix For: 1.0.13, 1.2
>
>         Attachments: OAK-2404.patch
>
>
> There is currently no way to distinguish between a {{SegmentNotFoundException}} occurring because of a removed segment by gc or because of another corruption. Optimally we would tell in the exception why the segment is gone, how old it was when gc removed it and who/what was still referring to it at that time. In order to do that, we probably need some kind of log for the following data: When a segment was removed (because a new generation of the .tar file was made, or because the .tar file was removed), we should log the segment, the file name, and the date+time of the removal. If the segment was then not found because it was too old, then another type of exception should be thrown instead, for example "ReadTimeoutException", with a message that contains as much data as possible: the data+time of the segment, date+time of the removal of the segment, about when compaction was run, date+time of the session login and last refresh, the stack trace of where the session was acquired.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)