Today, the embedded node feature only allow a single embedded node with management enabled, because it is not possible to distinguish the MBeans of a node from those of another node.
We propose to change that to make it possible to have multiple embedded nodes in the same JVM.
In which release
Latest JPPF version, for inclusion in the upcoming v6.3
Do you have suggestions on how to implement it?
The following approaches may be considered:
The node MBeans should have a discriminant property/metadata to ensure they can be uniquely assoaciated with a single node. The node UUID appears to be the best candidate for that purpose. As an example, the object name of a node admin MBean would change from:
org.jppf:name=admin,type=node
to
org.jppf:name=admin,type=node,uuid=D935ED79-5FB3-477F-9688-E7689AAF9AC9
Another possibility is to use a different MBean Server for each embedded node, with the first node using the default platform mbean server. This seems to be the least disruptive approach and wouldn't break the exiting management and monitoring capabilities.
What should be improved
Today, the embedded node feature only allow a single embedded node with management enabled, because it is not possible to distinguish the MBeans of a node from those of another node.
We propose to change that to make it possible to have multiple embedded nodes in the same JVM.
In which release
Latest JPPF version, for inclusion in the upcoming v6.3
Do you have suggestions on how to implement it?
The following approaches may be considered:
The node MBeans should have a discriminant property/metadata to ensure they can be uniquely assoaciated with a single node. The node UUID appears to be the best candidate for that purpose. As an example, the object name of a node admin MBean would change from:
org.jppf:name=admin,type=nodetoorg.jppf:name=admin,type=node,uuid=D935ED79-5FB3-477F-9688-E7689AAF9AC9Another possibility is to use a different MBean Server for each embedded node, with the first node using the default platform mbean server. This seems to be the least disruptive approach and wouldn't break the exiting management and monitoring capabilities.