[
https://issues.apache.org/jira/browse/MESOS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-510:
----------------------------------
Description:
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)",
was:
One example is the ResourceMonitor. 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 so I'd
like to bundle it with a widespread statistics refactoring.
> 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)",
--
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
