![]() Please wait while updating issue type...
Could not save your changes
This issue has been changed since you started editing it
Data that has been changed is highlighted in red below. Undo your changes to see the updated information
You have changed this issue, but haven't saved your changes yet. To save it, press the Save changes button to the right
This issue is blocking the next release
![]() There are no comments
There is nothing attached to this issue
This issue has no duplicates
There are no code checkins for this issue |
|||||||||||||||||||||||||||||
Really delete this comment?
Adding a separate method also has the advantage that you can still specify the maximum number of nodes, so it keeps its current meaning.
Really delete this comment?
Really delete this comment?
Really delete this comment?
Really delete this comment?
Really delete this comment?
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?
Really delete this comment?
Really delete this comment?
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).
Really delete this comment?
Local nodes can be distinguished in an execution policy with the property "jppf.channel.local = true" or with JPPFManagementInfo.isLocal()
Really delete this comment?
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?
Really delete this comment?
Really delete this comment?