To simplify execution policy customization it would be nice if there were "AcceptAll" and "RejectAll" execution policies available.
Or simply "empty" but then it is non-obvious if if accepts or rejects everything.
These are useful for eg. disabling parts of rule "and(config, rejectAll)" / "or(config/ acceptAll)".
Currently, the communication between JPPF servers and client is based on a synchronous request/response model. As a consequence, a connection can only handle a single job at a time. This can impair the scalability of JPPF applications.
We propose to switch to an asynchronous model where each connection can handle multiple jobs, removing or mitigating the need for multiple connections.
JPPF 6.1 will stop supporting Java 7, whose end-of-life happened a long time ago.
The first step will be to make the compilation, build and tests pass without errors or warnings.
Usage of Java 8 new features and APIs will be either progressive, while writing new code or updating existing code, or systematic in some cases if we determine that the benefits are worth it.
The first difficulty will be to refactor or rewrite the custom doclet code we use for the @exclude tag used in the javadoc.
The SLA of each JPPF job has a classpath attribute which allows the job to transport a set of jar files to dynamically add to its classloader when it is executed on a node.
There are currently a number of problems with the classpath itself and with the way it is handled by the node:
* classpath elements refer to a "local" and a "remote" location. The semantics here is confusing and we propose to use "source" and "target" locations instead
* there is currently no way to avoid downloading jar files if they already exists on the file system. We should allow a flow to allow it, make it default to false to preserve the existing behavior as a default
* the notion of "force classloader reset" isn't clear ly explained and does not work as documented. This shouid be fixed
Many JPPF classes use JSR 223-compliant scripts to perform their functionality:
* scripted tasks
* scripted execution policies
* scripted node selectors
* scripted job selectors
* scripted validation function in ClassPathElementImpl
We propose to introduce a new class ScriptDefinition which groups the attributes needed to execute the scripts:
* script: the actual script content as text
* bindings: an optional set of variable bindings made available to the script
* reusableId: an optional identifier for the script which allows reusing the compiled form of the script so as to avoid uncessary recompilation of the script
One of the objectives is to simplify the code that uses scripts, in particular so as to hide the internal mechanism to cache and pool the scripting engines and reusable compiled scripts.
A longer-term objective (targetting JPPF v6.1) is to expose the ScriptDefinition class wherever scripts are used in the public APIs. This will simplify the exposed APIs while increasing flexibility and add consistency with regards to scripting.
We propose to add a configuration property in the JPPF driver, to specify that it should route jobs to other drivers only when its number of nodes is at most a given threshold. For example, if we define:
then the driver will only route jobs to peer drivers when it has less than 3 nodes. The default value would be infinite (say Integer.MAX_VALUE) to preserve the current default behavior. A value of 0 or less would mean that jobs are never routed to a peer driver.
When setting [https://www.jppf.org/doc/6.0/index.php?title=Job_Service_Level_Agreement#Expiration_of_job_dispatches '''job dispatch expiration'''] in a multi-server toplogy where the serers communicate with each other, if a job is dispatched by driver D1 to its peer driver D2, then upon expiration the job is not cancelled is D2 and remains stuck there unless manually cancelled (via the admin console or via API).