This is a very interesting feature request. I see that it will be very difficult to implement and I don't think it will fit in the schedule for v4.2 planned for July 15th. As a rule, we never provide new features in a maintenance release. We can sometimes cheat by disguising a feature as an enhancement, but this one is too disruptive of the existing code to fit in.

As a preliminary reflection, and as a base for discussion and investigation, here are my initial thoughts, in no particular order:

• this will change the way job scheduling is done in the server
• this feature introduces a potential semantic conflict with regards to the job SLA: the SLA's purpose is to filter out nodes that do not match it, whereas the present proposal is to make the nodes match the SLA. We'll need to find a way to reconcile the two, but we can imagine the magnitude of the design change this implies
• a major difficulty is to "reserve" a node for a given job, ensuring no other job is scheduled for that node. A possibility could be to use an exclusion list in the server, where each node in the list is mapped to a job.
• a possibility could be to do this using the node provisioning feature: instead of restarting the node, we deactivate it, provision a single slave node (eventually unprovisioning an already existing slave first), add as a configuration override to the slave a property like "job.uuid = job_identifier" and then add this as a criteria for the job scheduling, maybe as part of a custom execution policy or a scripted policy.

Hi, Thanks for considering my enhancement. We are evaluating the possibility of using JPPF as a replacement for a commercial product.

The concept behind the request comes from this commercial product. A task has an node filter where it is possible to filter on a nodes properties (OS, Ram, Cores, custom, etc.) The JVM version and number of threads is *not* part of the node filter but rather the task's requested node configuration. So a task could specify a node filter (e.g. OS=Windows,Cores=4) and also a node configuration (e.g. JVM1.8, threads=8 ). The thread count doesn't trigger a restart, changing the JVM might trigger a restart if the correct version wasn't already running. Also a task can ask that the the JVM to always be restarted.

The reconfiguration of a node allows many different tasks to coexist on the same grid. Some tasks have there own threading and don't want the node to process many tasks at once, others are single threaded and it makes sense to have the node processes many jobs simultaneously.

I understand it might not follow your model - I expected that. I wanted to throw it out there to see what was possible today and make sure I wasn't missing anything.

I appreciate your reply and attention. You have an amazing product and it's great to see you actively supporting it.

Regards, Roger

Now that the ability to specify the JVM path has been implemented in Feature request JPPF-176 - Enable specifying the JVM location for the driver and node launcher, all that remains to do is:

• add the appropriate attribute(s) to the job SLA to describe the desired node configuration and tell the server to restart the node with that configuration. We could try and compute a similarity score for each eligible node, and use the ndoe with the highest score
• add the ability to reserve a node for a specific job - it could be a good idea to have a timeout on the reservation, to avoid having nodes waiting for a job that is no more

Implemented in trunk revision 4023