Print

[groostav]

Hey guys,

I think this must be a common case but I'm not sure how to handle it.

Lets say we've got three nodes. Lets say we've got a Task of 'Type A' (as per execution policies). All of these nodes are capable of executing Type A tasks, however, only 2 tasks of Type A may be executing at any instant in time. This is because of licensing.

So, for example, if we have four tasks {T1, T2, T3, T4}, all of type A, and three machines {A, B, C}, then one valid schedule is

start
T1 dispatched to A
T2 dispatched to B
T1 completes
T3 dispatched to A
T2 completes
T4 dispatched to B

but the obvious (greedy) schedule would not be valid:

T1 dispatched to A
T2 dispatched to B
T3 dispatched to C
T1 completes
T4 dispatched to A

this is not a valid schedule since there are three tasks running at the same time.

As a java developer I immediately thought about how this could be solved with a complex scheduler on our side (the side that calls job.submit()), and I thought about how it could be solved if I had some magical network-shared memory that I could put an ArrayBlockingQueue in, but the former is difficult and the latter isn't possible.

How can I get the synchronize-and-count behaviour that I need to ensure that the JPPF server does not dispatch tasks illegally?

Is my best bet to implement a custom load balancer?

thanks for any help

[lolo]

Hello,

One thing that will help you is the ability to set the maximum number of nodes a JPPF job (I believe that's what you mean by "task", is this correct?)  can execute on at any given time. This is an attribute of the job SLA, which is set as follows:

Code: [Select]

JPPFJob job = new JPPFJob();
job.setMaxNodes(2);
Then, there remains the problem of multiple tasks (in JPPF terminology: instances of AbstractTask) being dispatched to each job, which may be executing concurrently in each node.
There are multiple ways to handle this:

1) you may already handle this in your tasks, soemhow sequentializing access to the licensed service or library

2) you could unconditionally configure each node with a single processing thread - this would however, limit the performance of all jobs, including those that don't have licensing constraints

3) you could dynamically update the number of processing threads, for instance from a NodeLifeCycleListener and based on job metadata, as in this example:

Code: [Select]

import org.jppf.management.JMXNodeConnectionWrapper;
import org.jppf.node.event.*;

// sets the number of processing threads based on job metadata
public class MyNodeListener extends NodeLifeCycleListenerAdapter {
  private static final String LICENSING_PARAM = "has.license.constraint";
  private int maxThreads = 0;
 
  @Override
  public void jobStarting(NodeLifeCycleEvent event) {
    if (event.getJob().getMetadata().getParameter(LICENSING_PARAM, false)) {
      setConstraintState(true);
    }
  }

  @Override
  public void jobEnding(NodeLifeCycleEvent event) {
    if (event.getJob().getMetadata().getParameter(LICENSING_PARAM, false)) {
      setConstraintState(false);
    }
  }

  private void setConstraintState(boolean active) {
    // obtain a local node management wrapper object
    JMXNodeConnectionWrapper jmx = new JMXNodeConnectionWrapper();
    jmx.connect();
    try {
      if (active) {
        // set the max num of executing threads
        this.maxThreads = jmx.state().getThreadPoolSize();
        jmx.updateThreadPoolSize(1);
      } else {
        // restore the max num of executing threads
        jmx.updateThreadPoolSize(this.maxThreads);
      }
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}
4) you can also set the server's load balancing configuration to a fixed size of 1, with basically the same performance impact as 2) :

Code: [Select]

jppf.load.balancing.algorithm = manual
jppf.load.balancing.profile = test
jppf.load.balancing.profile.test.size = 1
5) You could use a custom load-balancer that would have access to the job and would send only one task to the node when the job has licensing constraints. This is probably the most complex option to implement.

I guess that's a nice array of options we have here

Sincerely,
-Laurent

PS: I think this topic would be a better fit in the "Developers help" forum. If you're ok with this, I will move it there.