Hi,
On 14/01/16 01:26, "Vikas Saurabh" wrote:
>There's a bit of respite on trunk (due to [1] and friends) and a
>sequence of events like {{t1 -> update lease}}, {{t2=t1+7.5hrs ->
>commit}} would lead to a shutdown as a big jump like 7.5 hours would
>be beyond lease end time. BUT, if there's lease update before a commit
>after a clock jump, then even on trunk there's no safeguard.
>If we update lease update logic to shut down as well in case it can't
>update lease for a long time then an instance with forward jumping
>clock would self-destruct.
Please note, this is not sufficient. We should also introduce a
a check when a commit revision is created. The revision timestamp
must always be less than the leaseEnd time. In addition with your
above proposal, that should prevent commits with a future revision
caused by clock jumps.
Could you please create an issue for this?
>BTW, the approach mentioned above saves only agains a clock which
>jumps ahead directly. We'd still have similar issue for a clock slowly
>skews forward. But, even then I think it's worth it to have to solve
>the particular case.
this is probably less of an issue, because you'd notice it at some
point. Commits on the cluster nodes with the correct clock would
get delayed and WARN messages appear in the logs.
Regards
Marcel
