You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Jie Yu (JIRA)" <ji...@apache.org> on 2014/03/31 19:13:15 UTC
[jira] [Commented] (MESOS-1165) Retry required when recovering an
empty log
[ https://issues.apache.org/jira/browse/MESOS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955392#comment-13955392 ]
Jie Yu commented on MESOS-1165:
-------------------------------
https://reviews.apache.org/r/19852/
> Retry required when recovering an empty log
> -------------------------------------------
>
> Key: MESOS-1165
> URL: https://issues.apache.org/jira/browse/MESOS-1165
> Project: Mesos
> Issue Type: Bug
> Reporter: Jie Yu
> Priority: Minor
> Fix For: 0.19.0
>
>
> Reported by [~benjaminhindman]. It's fairly non-intuitive that a 'fill' retry is required when recovering an empty log. Moreover, since retry is done via a 'delay' it means that you can't pause the clock before calling Log::Writer::start! The following tests show the multiple calls and at one point I added comments to explain the very esoteric reasoning here. Here are the sequence of events:
> First a replica is recovered with nothing but 0 is always a hole:
> ----
> Replica recovered with log positions 0 -> 0 with 1 holes and 0 unlearned
> ----
> At this point the replica assumes it was promised to a coordinator with proposal 0 (that's the default metadata). Then an implicit promise request is made with proposal 1.
> ----
> Replica received implicit promise request with proposal 1
> ----
> Then the coordinator (via FillProcess) tries to fill the hole (position 0) explicitly:
> ----
> Coordinator attemping to fill missing position
> ----
> And the replica receives the request:
> ----
> Replica received explicit promise request for position 0 with proposal 1
> ----
> But the filling must be retried because the 0th position is implicitly promised to proposer 1 (the same coordinator!) but the replica won't allow it (because it might not be safe) so the FillProcess now tries with proposal number 2 (after the delay). While correct, this seems unfortunate (and not intuitive).
--
This message was sent by Atlassian JIRA
(v6.2#6252)