[
https://issues.apache.org/jira/browse/MESOS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726936#comment-13726936
]
Vinod Kone commented on MESOS-510:
----------------------------------
Should we restrict the slaves to 1 till this is fixed? I keep getting segfaults
when running local tests because of this.
> Multi-slave local runs broken due to non generated libprocess Process ID
> names.
> -------------------------------------------------------------------------------
>
> Key: MESOS-510
> URL: https://issues.apache.org/jira/browse/MESOS-510
> Project: Mesos
> Issue Type: Bug
> Reporter: Benjamin Mahler
> Assignee: Benjamin Mahler
>
> The following libprocess Processes need to be updated to use non-generated
> process IDs, and thus have issues on local runs.
> * Files.
> * ResourceMonitor.
> * Master (although, local runs currently only allow a single Master so
> nothing is broken here, currently).
> Which uses a libprocess Process ID name of "monitor". Consequently, when a
> local run spawns several slaves, all slaves will dispatch to the last
> ResourceMonitorProcess to register with the "monitor" name.
> The fix here is to implement: https://issues.apache.org/jira/browse/MESOS-322
> But the implications are that it changes the slave / master endpoints. One
> workaround is to have ID::generate("foo") do the following:
> 1. If this is the first generated ID, assign both "foo" and "foo(1)" to this
> process. This maintains backwards compatibility.
> 2. For all remaining nth IDs, assign "foo(n)" as the ID.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
