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).
Currently in the JPPF client, the discovery of drivers from the configuration is a separate mechanism from the [https://www.jppf.org/doc/6.0/index.php?title=Custom_discovery_of_remote_drivers '''driver discovery'''] extension. We want to make it a built-in default implementation instead.
We propose to add a new implementation of the [https://www.jppf.org/javadoc/6.0/index.html?org/jppf/location/Location.html '''Location'''] interface, named MavenCentralLocation. This class inherits from [https://www.jppf.org/javadoc/6.0/index.html?org/jppf/location/URLLocation.html '''URLLocation'''] and merely add constructors to allow specifying artifacts to download from Maven central in the form "groupId:artifactId:version".
Additionally, the documentation section on the lcoation API should be moved from the "Development guide > Task objects" page to its own page under "Development guide"
we get sometimes the following deadlock, when we send new tasks to our jppf server. Our code checks before the start, if there are any available connections to jppf server by JPPFClient#hasAvailableConnection. In case that there are no connections available the task is canceled.
Sometimes our application hangs in this process. jstack shows that there is a deadlock between TaskQueueChecker-thread and the thread, where hasAvailableConnection is called.