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 "Julian Reschke (JIRA)" <ji...@apache.org> on 2018/02/21 12:49:00 UTC
[jira] [Issue Comment Deleted] (OAK-7272) improve
BackgroundLeaseUpdate warning messages
[ https://issues.apache.org/jira/browse/OAK-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated OAK-7272:
--------------------------------
Comment: was deleted
(was: Proposed change inhttps://issues.apache.org/jira/secure/attachment/12910933/OAK-7272.diff )
> improve BackgroundLeaseUpdate warning messages
> ----------------------------------------------
>
> Key: OAK-7272
> URL: https://issues.apache.org/jira/browse/OAK-7272
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-7272.diff, OAK-7272.diff
>
>
> Example for current logging:
> {noformat}
> *WARN* [DocumentNodeStore lease update thread (1)] org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore BackgroundLeaseUpdate.execute: time since last renewClusterIdLease() call longer than expected: 5338ms
> {noformat}
> Source:
> {noformat}
> @Override
> protected void execute(@Nonnull DocumentNodeStore nodeStore) {
> // OAK-4859 : keep track of invocation time of renewClusterIdLease
> // and warn if time since last call is longer than 5sec
> final long now = System.currentTimeMillis();
> if (lastRenewClusterIdLeaseCall <= 0) {
> lastRenewClusterIdLeaseCall = now;
> } else {
> final long diff = now - lastRenewClusterIdLeaseCall;
> if (diff > 5000) {
> LOG.warn("BackgroundLeaseUpdate.execute: time since last renewClusterIdLease() call longer than expected: {}ms", diff);
> }
> lastRenewClusterIdLeaseCall = now;
> }
> // first renew the clusterId lease
> nodeStore.renewClusterIdLease();
> }
> {noformat}
> Observations:
> - the warning message doesn't actually say what the expected delay is
> - we only log when it's exceeded by factor 5
> - the threshold is hardwired; it should be computed based on the actual config (I think)
> Also:
> - we don't measure the time of the actual update operation, so we don't know whether it's a thread scheduling problem or a persistence problem (again, I think)
> [~egli], [~mreutegg] - feedback appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)