Print

[prsiv]

Hello All,

Any suggestions on how to approach restricting node use by time?  I have several workstations available for use by jppf but I want to have them unavailable to jobs during business hours.

Suggestions?

Thanks,
Paul

[lolo]

Hi Paul,

Currently we don't have anything that would fit the bill exactly.
We have a feature request JPPF-24 Ability to deactivate a node that should allow a lot of flexibility in this regard, but it won't be part of the next release (3.2).

Some possibilities:
- the obvious one is to use cron jobs on Linux/Unix or the task scheduler on Windows to start/kill a node. You can use a script which launches a java program to run a node, or to kill it via the JMX APIs
- you can also use the idle mode, which starts a node when the workstation is idle (i.e. no keyboard or mouse input for a configurable time), and kills it as soon as the user uses the keyboard or mouse. That's definitely not scheduling, though, and it won't work if the node runs as a service or daemon.
- another possiblity would be to use a custom execution policy on your jobs, which would fetch a schedule and match nodes against it. This is probably the most viable solution I can see.

Sincerely,
-Laurent

[prsiv]

Laurent,

Thanks for the suggestion of using a custom Job Service Level Agreement.   I think I can make that work.

Paul

[prsiv]

Where do I reference CustomRule that will invoke my custom SLA for checking the node name and time before accepting a job?  The documentation says to put the CustomRule in an xml file but how is this xml file then referenced by jppf so that it is processed and my custom SLA used?

Thanks,
Paul

[lolo]

Hi Paul,

The custom execution policy must be set onto the job's SLA as a Java object before you submit it for execution:

Code: [Select]

JPPFJob job = ...;
job.getSLA().setExecutionPolicy(new MyCustomPolicy(param1, ..., paramN));
jppfClient.submit(job);
One of the implications is that you must also have MyCustomPolicy available in the driver's classpath, so that there is no issue when the driver deserializes the job SLA. Ideally, you should have it, along with the required classes, in a separate jar which does not include the code for your tasks, so as not to interfere with the dynamic classs loading for your tasks.

I acknowledge that this is not addressed in our documentation. I registered a documentation bug for it: JPPF-100 Missing deployment instructions for custom execution policies

I hope this clarifies.

-Laurent