JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-395  -  Let JobSLA's maxNodes include/exclude provisioned slaves
Posted May 14, 2015 - updated May 17, 2015
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
     Daniel Widdis
  • Owned by
    Not owned by anyone
  • Category
    Node
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 5.1
Issue description
I have recently implemented distributed maps on my nodes using Hazelcast, where each physical server (Master node + slaves) represents a cluster. I am looking to further leverage the benefits of this cache by assigning tasks with significant data overlap to the same server. Simply stated, I would like tasks from "Job A" to only execute on a master node and its slaves (if any).

Unfortunately this does not appear to be easily implemented. The JobSLA class setMaxNodes() method is similar to what I would want, except it would not enforce any relationship between nodes selected. I've considered an approach using Execution Policies to favor certain servers by IP, but my cloud IP addresses are not known when my client submits the tasks.

I can see two possible improvements in JobSLA which would enable my desired capability:
  • Add an argument to setMaxNodes(), or a new method, which applies the maximum only to Master Nodes; and permits assignment to the slave nodes of the assigned master. e.g., setMaxMasterNodes(2) would limit that job to processing on two master nodes and their corresponding slave(s), if any.
  • Add a method setMaxProperties(int n,String key) which would evaluate the same properties used in Execution Policies and permit only a maximum of n unique values of the property identified by key. e.g., setMaxProperties(2,"ipv4.addresses") would allow that job to execute on no more than two unique servers (as determined by matching the IP addresses string).

#1
Comment posted by
 lolo4j
May 15, 08:53
Thank you Dan, I always love the challenges you give me :). I definitely prefer the first option, adding a get/setMaxMasterGroups(int). Note that I replaced "MasterNodes" with "MasterGroups" as I believe it is semantically more accurate. Maybe "MasterNodeGroups" would be even better? I don't think it's a dummy question since ultimately it's a public API that will be exposed to all the users.

Adding a separate method also has the advantage that you can still specify the maximum number of nodes, so it keeps its current meaning.
#3
Comment posted by
 lolo4j
icon_reply.pngMay 15, 09:14, in reply to comment #1
I'm also conisdering the following:
  • the default value will be Integer.MAX_VALUE, and setting a value <= 0 will have no effect. There will be a specific check in the code to avoid the computation when maxMasterNodeGroups == Integer.MAX_VALUE, since it has a cost.
  • this setting will not take into account the nodes that are neither master nor slave: offline nodes and soon to come Android nodes. Filtering those out should be done in the execution policy.
#4
Comment posted by
 lolo4j
May 15, 21:10
Implemented in trunk revision 3732
#6
Comment posted by
 Daniel Widdis
May 15, 21:19
I enjoy providing you challenges!

Have you established a terminology yet for what a grouping of master+slaves is called? I'm not sure "MasterGroups" is appropriate. I like NodeGroups. Since this is related to node provisioning, perhaps NodeProvisionGroups ?

I'm not sure what you mean by "not take into account ... offline and Android nodes." Does that mean they each count as a "node group" and would need to be excluded separately using a policy "isMaster OR isSlave"? Or that jobs assigned to these non-master/slave nodes do not count against the total max? Is there an execution policy that could limit jobs to be assigned to these NodeProvisionGroups (e.g., the job can only go to a slave node, or a master node whose nbSlaves value is > 0) so that a master node with no slaves wouldn't get a job?
#7
Comment posted by
 Daniel Widdis
icon_reply.pngMay 15, 21:42, in reply to comment #6
Also are server local nodes in the "non-master/slave" cateogry as well?
#8
Comment posted by
 lolo4j
icon_reply.pngMay 15, 21:45, in reply to comment #6
I'm using the term "MasterNodeGroup" in the currently committed implementation. I can still change it if you think 'NodeProvisionGroups" sounds better. Or maybe "NodeProvisioningGroups", since it's closer to what already exists in the docs?

What I mean by 'not taken into account' is that these offline nodes are not counted as node provisioning groups and will be accepted if no other restriction/filtering is set. In other words, it means the node provisioning groups attribute does not apply to them. Thus yes, they'd have to be excluded separately with an execution policy like new ExecutionPolicy.Not(new Equal("jppf.node.offline", true)), or if you prefer, something like new Equal("jppf.node.provisioning.master", true).or(new Equal("jppf.node.provisioning.slave", true)). To restrict to slave nodes only, just keep the new Equal("jppf.node.provisioning.slave", true).
#9
Comment posted by
 lolo4j
icon_reply.pngMay 15, 23:21, in reply to comment #7
Also are server local nodes in the "non-master/slave" cateogry as well?
Nope, they are full fledged master nodes and can have their own slaves. I wish I could too, so we could have all features implemented for the initially planned deadline!

Local nodes can be distinguished in an execution policy with the property "jppf.channel.local = true" or with JPPFManagementInfo.isLocal()
#10
Comment posted by
 Daniel Widdis
icon_reply.pngMay 16, 03:21, in reply to comment #8
lolo4j wrote:
I'm using the term "MasterNodeGroup" in the currently committed
implementation. I can still change it if you think 'NodeProvisionGroups"
sounds better. Or maybe "NodeProvisioningGroups", since it's closer to what
already exists in the docs?


I've gone back and forth on this. The docs aren't very helpful, primarily referring to "provisioning slaves" and rarely mentioning master except in the phrase "master/slave" and noting that "standard nodes" are master nodes. So I thought MasterSlaveGroups might work, but the restriction should still apply to a master node with no slaves so I don't like that. In which case MasterNodeGroups is just fine and I'm warming up to it.

I think I still prefer NodeProvisioningGroups, however. Is variable/method naming the hardest part of Java?
#11
Comment posted by
 lolo4j
May 16, 12:17
Ok, I'll go with NodeProvisioningGroups. It's not so much that naming is hard: as we just demonstrated, we easily come up with meaningful names. The hard part is keeping naming consistency accross hundreds or thousands of artifacts and getting a feel of the impact on existing installations. I've made numerous mistakes in the past which I now regret, and these things do have a way of acquiring enormous momentum. Well, I'll just have to live with that and make my imperfection an axiomatic assumption.
#12
Comment posted by
 lolo4j
May 17, 06:04
Changed the name and fixed doc in revision 3733