jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-6836) OnRC report
Date Fri, 15 Dec 2017 11:20:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292370#comment-16292370

Michael Dürig commented on OAK-6836:

Instead of calling {{GCMonitor}} methods directly from {{FileStore}} it might more sense to
call specific methods (to be added) of {{GCListener}} and delegate from there to the rreported
and {{GCMonitor}} (and not extend {{GCListener}} from {{GCMonitor}}. This way the {{FileStore}}
has a single listener to report into. Also that listener is private to {{oak-segment-tar}}
and we can freely evolve it as required. 

> OnRC report
> -----------
>                 Key: OAK-6836
>                 URL: https://issues.apache.org/jira/browse/OAK-6836
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Valentin Olteanu
>            Priority: Minor
>              Labels: production
>         Attachments: gcreport.png
> Currently, the information regarding an online revision cleanup execution is scattered
across multiple log lines and partially available in the attributes of {{SegmentRevisionGarbageCollection}}
> While useful for debugging, this is hard to grasp for users that need to understand the
full process to be able to read it.
> The idea would be to create a "report" with all the details of an execution and output
it at the end - write to log, but also store it in the MBean, from where it can be consumed
by monitoring and health checks. 
> In the MBean, this would replace the _Last*_ attributes.
> In the logs, this could replace all the intermediary logs (switch them to DEBUG).

This message was sent by Atlassian JIRA

View raw message