[
https://issues.apache.org/jira/browse/OAK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-2404:
-------------------------------
Attachment: OAK-2404.patch
[^OAK-2404.patch] logs the segment ids of the segments removed by cleanup. When
testing this on a medium sized repository with a lot of garbage (12GB
compactable to 2GB) the extra amount of logging is 4MB spread over 26000 log
lines. On average I've seen 550 log lines per cleaned tar file.
How should we handle this amount of extra information? I already log to a
different logger so applications could redirect this to a dedicated appender.
Currently the log level is at INFO as I figure we want to have this information
per default. But still I fear the people come back shouting spam when I check
this in. WDYT?
cc [~alex.parvulescu], [~mmarth]
> 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)
