Now that nodes can process multiple jobs concurrently, it seems the next logical step is to allow these jobs to come from any number of JPPF drivers. In particular, this will address the problem of the driver being a single point of failure more efficiently.
This will impact manay areas of the code, including:
* processing within the node (of course)
* handling of connection/disconnection events in the node (node connection strategy, when should a node reconnect)
* should we allow the driver connections to be prioritized, as in the client, and permit a failover hierarchy of drivers?
* grid topology monitoring: the topology will no longer be a tree. In particular, the nodes will have multiple drivers as parents, which is a significanty change in the monitoring object model
* how iwll it affect load-balancing?
JPPF 6.2 introduced the concept of dependencies between Tasks and also between Jobs. It would be nice if this feature could be expanded with Tasks/Jobs having access to the result-value of the tasks/jobs it depends on.
We propose to implement a sample to demonstrate how to avoid JPPF drivers as single points of failure, with the following aspects:
* multiple drivers, not connected to each other (i.e. in pure failover mode). Each driver has a priority, the nodes connect only to the driver that is running with the highest priority
* a specific [https://www.jppf.org/doc/6.3/index.php?title=Defining_the_node_connection_strategy node connection strategy] for all the nodes, which allows the nodes to connect the driver that is up with highest priority
* a JPPF client as a controller, to detect when a driver with the highest priority goes back up, and force the nodes to reconnect to it
We propose to refactor the class representing the local executor in a JPPFClient, such that it implements the [https://www.jppf.org/javadoc/6.3/org/jppf/client/JPPFClientConnection.html JPPFClientConnection] interface. This will, in particular, allow a clearer semantics for the connection status events. Consequently, JPPFClientConnection should allow to distinguish between local and remote connections (with a isLocal() method for instance).
Whenever a JPPFClient attempts to connect to a driver, it will print out the status of the connection attempt to stdout. This can generate a lot of output whe'n there are many connections, and it may be desirable to disable the output. It will still be printed to the log.
Due to an error in the code, when registering multiple [https://www.jppf.org/doc/6.2/index.php?title=Managing_and_monitoring_the_nodes_through_the_driver#Registering_JMX_notification_listeners forwarding notification listeers], only the first one is properly registered, causing the others to not receive notifications from the nodes.
The Maven central repository has switched to HTTPS only as of January 15th, 2020. As a consequence, the JPPF build fails to download its dependencies, since it uses http://repo.maven.apache.org/maven2/ as a basde url. this causes the compilation and the build to fail.
This affects the trunk/master, 6.1.x and 6.0.x versions