[ 
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)

Reply via email to