JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-608  -  Typed results map for JPPFNodeForwardingMBean methods
Posted Nov 01, 2019 - updated Nov 04, 2019
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Management / Monitoring
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 6.2
Issue description
Currentlly, methods in the JPPFNodeForwardingMBean class returns a mapping of node uuids to the result of the JMX request on the specified mbean for each node. For example:
public interface JPPFNodeForwardingMBean extends NotificationEmitter {
  Map<String, Object> state(NodeSelector selector) throws Exception;
}
This current approach has several flaws:
  • we document in the javadoc that the value of each entry in the returned map is either a JPPFNodeSate or an Exception, but there is nothing to enforce it at compile time
  • invocations that return null are often not included in the map, therefore we can't know exactly which nodes the request was sent to
Instead, we propose to enforce the type of the results with an interface like this:
public interface NodeForwardingMBean extends NotificationEmitter {
  Map<String, InvocationResult<JPPFNodeState>> state(NodeSelector selector) throws Exception;
}
Where InvocationResult would expose the following methods:
public class InvocationResult<R> implements Serializable {
  public boolean isException() { return ...; }
  public Exception exception() { return ...; }
  public R result() { return ...; }
}
To achieve this, we propose the following steps:
  • deprecate JPPFNodeForwardingMBean and related classes and APIs, but keep the mbean alive and active so it does not break existing code that uses it
  • define a new MBean which provides a very similar API but with strong typing of the results. Thus, there will be 2 mbeans doing the same thing until the deprecated one is removed.