jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Egli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4739) lease: immediate renew after long renew call
Date Fri, 02 Sep 2016 08:39:20 GMT

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

Stefan Egli commented on OAK-4739:
----------------------------------

Using the _recovery lock_ we should be able to distinguish the case where an instance failed
to update the lease (eg due to network hickup) but no other instance noticed this yet (including
discovery-lite) and a case where anyone noticed this. Basically we have clear state boundaries
between a lease being valid and an instance being in recovery state. If this is the case (and
I believe it is) then we could indeed do a retry in case the lease fails but the recovery
lock has not yet been acquired, no?

> lease: immediate renew after long renew call
> --------------------------------------------
>
>                 Key: OAK-4739
>                 URL: https://issues.apache.org/jira/browse/OAK-4739
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: documentmk
>    Affects Versions: 1.5.8
>            Reporter: Martin Böttcher
>              Labels: resilience
>
> A single temporary network issue can shut down the DocumentStore. We observed the following
situation:
> # org.apache.jackrabbit.oak.plugins.document.ClusterNodeInfo.renewLease was called (this
is done regularly and completely normal)
> # the network had a temporary issue (whatsoever)
> # the database call terminated after a lot of time (the default db maxWaitTime is 120
seconds).
> # org.apache.jackrabbit.oak.plugins.document.ClusterNodeInfo.renewLease decides that
the current lease is too old (>120 seconds thats the default for the oak.documentMK.leaseDurationSeconds
property), sets a leaseCheckFailed variable and throws an Exception
> # because leaseCheckFailed is set all following tries (if any) will immediately throw
an Exception, too.
> I'd recommend to make the ClusterNodeInfo code more robust so that at least one retry
will be made.



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

Mime
View raw message