jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Dulceanu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4097) Add metric for FileStore journal writes
Date Tue, 19 Jul 2016 07:58:20 GMT

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

Andrei Dulceanu commented on OAK-4097:

I'd like some advice regarding how to approach this issue. One way would be to add a {{{FileStoreMonitor}}}
instance variable in {{{TarRevisions}}} and have a new {{{FileStoreMonitor::flushed()}}} method
being called at each {{{TarRevisions::flush()}}} invocation. IMO this would satisfy the requirement,
since {{{TarRevisions::flush()}}} is the only place where a journal write happens.

On the other hand, as suggested by [~frm], we could intercept calls to {{{org.apache.jackrabbit.oak.segment.WriteOperationHandler::flush()}}}
"since this method guarantees that pending changes in in-memory segments are persisted on
disk via a write." I think this is a more general approach, but since {{{WriteOperationHandler::flush()}}}
is called in {{{SegmentWriter::flush()}}} which in turn is called in numerous places (including
{{{FileStore::flush()}}} which causes also the journal write), without necessarily modifying
the journal file, I'd assume the metric collected would be one related to {{{FileStore}}}
writes, not to journal writes.

Any ideas on how to move this forward?

> Add metric for FileStore journal writes
> ---------------------------------------
>                 Key: OAK-4097
>                 URL: https://issues.apache.org/jira/browse/OAK-4097
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Chetan Mehrotra
>            Assignee: Andrei Dulceanu
>            Priority: Minor
>             Fix For: 1.6, Segment Tar 0.0.6
> TarMK flush thread should run every 5 secs and flush the current root head to journal.log.
It would be good to have a metric to capture the number of runs per minute
> This would help in confirming if flush is working at expected frequency or delay in acquiring
locks is causing some delays

This message was sent by Atlassian JIRA

View raw message