[
https://issues.apache.org/jira/browse/MESOS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13728183#comment-13728183
]
Benjamin Mahler commented on MESOS-510:
---------------------------------------
Discussed this one with benh. We can simply change the ResourceMonitor to use
ID::generate. However, this requires an export of the monitor's PID via the
slave's state.json endpoint. This can be avoided if we had the ability to
forward messages. e.g. /slave(1)/monitor forwards to /monitor(n) where
monitor(n) is the monitor PID for slave(1).
That being said, I'll look into the primitives we would need in libprocess for
request forwarding, but if it's a lot of work I'll punt and go with the easier
solution for now.
> 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
