[ https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998884#comment-14998884 ]
haosdent edited comment on MESOS-3870 at 11/10/15 4:49 PM: ----------------------------------------------------------- I think have another case make same Process run in different thread. Suppose ProcessBase pop event A in thread 1 and change ProcessBase.state to BLOCKED in https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L2463 . And not yet consume event A. Then event B reach and enqueue same Process to ProcessManager.runq in https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L3008 . Then ProcessManager dequeue it in thread 2 and pop event B and run event B while thread 1 not yet running event A consume function. Is this possible? was (Author: haosd...@gmail.com): I think have another case make same Process run in different thread. Suppose ProcessBase pop event A in thread 1 and change ProcessBase.state to BLOCKED in https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L2463 . And not yet consume event B. Then event B reach and enqueue same Process to ProcessManager.runq in https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L3008 . Then ProcessManager dequeue it in thread 2 and pop event B and run event B while thread 1 not yet running event A consume function. Is this possible? > Prevent out-of-order libprocess message delivery > ------------------------------------------------ > > Key: MESOS-3870 > URL: https://issues.apache.org/jira/browse/MESOS-3870 > Project: Mesos > Issue Type: Bug > Components: libprocess > Reporter: Neil Conway > Priority: Minor > Labels: mesosphere > > I was under the impression that {{send()}} provided in-order, unreliable > message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, <M1>, <M2>, > or <M1,M2> — but not <M2,M1>. > I suspect much of the code makes a similar assumption. However, it appears > that this behavior is not guaranteed. slave.cpp:2217 has the following > comment: > {noformat} > // TODO(jieyu): Here we assume that CheckpointResourcesMessages are > // ordered (i.e., slave receives them in the same order master sends > // them). This should be true in most of the cases because TCP > // enforces in order delivery per connection. However, the ordering > // is technically not guaranteed because master creates multiple > // connections to the slave in some cases (e.g., persistent socket > // to slave breaks and master uses ephemeral socket). This could > // potentially be solved by using a version number and rejecting > // stale messages according to the version number. > {noformat} > We can improve this situation by _either_: (1) fixing libprocess to guarantee > ordered message delivery, e.g., by adding a sequence number, or (2) > clarifying that ordered message delivery is not guaranteed, and ideally > providing a tool to force messages to be delivered out-of-order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)