We propose to add Docker images for JPPF, for drivers, nodes and web admin console. The configuration of a JPPF grid with docker should allow any kind of JPPF topology, including multi-server topologies.
The class [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/scheduling/JPPFSchedule.html JPPFSchedule] is used to specify the start or expiration schedule of a job, as well as the expiration schedule of a task. It currently has 2 basic constructors, one that takes an epoch time in millis, the other that takes a string which represents a date, along with a SimpleDateFormat-compliant format to parse it.
We propose to extends this class to enable building JPPFSchedule objects based on the classes in java.time.*, such as ZOnedDateTime, Duration, etc.
When a job is dispatched to multiple nodes in parallel, this can result in the same class loading request being issued to the same client in parallel or in sequence. This would happen when identical requests are forwarded to the same client, before the first response is received by the server, and therefore before in can be added to the server-side cache. It could be worthwhile, from a perfromance perspective, to use a cache of class definitions, such that identical requests (same client-side class loader and same resource path) only result in a single lookup in the classpath.
To this effect, we propose to implement a cache in the client, as follows:
* an identity hash map whose keys are class loaders
* the values are hash maps where the key is a path in the classpath and the value is the byte for the resource located at that path. These could be implemented as [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/utils/collections/SoftReferenceValuesMap.html SoftReferenceValueMap]s to avoid out of memory conditions due to the cache
The online and offline dosc still show, in the tutorial, code snippe that use the "blocking" job attribute, which is now deprecated, as well as job submission with JPPFClient.submitJob(), now deprecated and replace with submit() and submitAsync
This is about refactoring the distributed class loader communication model into the more efficient and scalable model introduced in JPPF 6.1 (see feature request JPPF-549 and feature request JPPF-564). This includes both driver/node and driver/client communication channels.
These are the last components to switch to the new model. Once it is done, we expect a number of benefits:
* we will be able to get rid of the old nio code, which should reduce the maintenance burden
* this should also increase the performance, simply because we will remove parts of the code inherited from the old model, which are still present but not used in the new model
* increased performance and scalability, because the new nio model is more efficient
We propose to enable dependencies between tasks in the same job. For instance, we envision the ability to express that task A depends on the completion of tasks B and C, who each depend on the completion of task D (diamond dependency graph):
This implies a number of challenges, including but not limited to:
* decide how to schedule and parallelize the execution of the tasks: a task with dependencies cannot be scheduled before its dependenices have completed
* handle failures / cancellation of tasks on which other tasks depend
* provide an expressive and intuitive API to specify the dependencies
We have a [https://www.jppf.org/samples-pack/JobDependencies/ job dependencies sample] which illustrates an ad-hoc way of executing acyclic graphs of dependent jobs.
We propose to make this an actual feature instead of a sample, and to explore other possibilities such as:
* a broader set of relationshups between jobs than just "depends on", e.g. split/join (or map/reduce). This implies to be able to gather global results for an entire job and apply transformations to these results.
* an expressive and intuitive way to build the job graph
Currently, [https://www.jppf.org/doc/6.1/index.php?title=The_Location_API#MavenCentralLocation MavenCentralLocation] only allows to download artifacts from Maven Central. We propose to add the ability to specify a different repository, as well as the ability to download SNAPSHOT artifacts, For instnce in a class nmamed MavenLocation, of which MavenCentralLocation could be a specialized subclass.
[https://www.jppf.org/doc/6.1/index.php?title=Monitoring_data_providers '''Monitoring data providers'''] allow to define properties of various types that are monitored over time. However, there is currently no way to specify how these values should be displayed in the JVM health view of the desktop and web administration consoles. JPPF currently uses default conversions based on the type of each property, but this may not be always convenient.
For instance, let's say we want to monitor the JVM uptime. This value is expressed in millisecons as a long integer value. However, in the GUI we'd rather have it displayed as days:hours:minutes:seconds.millis.
We propose to implement the ability to configure a value converter for each defined property to this effect.
For instance (just for example purpose, this is not what the actual design will be):
I would like to embed jppf-admin-web into my own embedded webserver as an executable jar. I need jppf-admin-web as a jar dependency instead of war to make this work. I would define my own web.xml for this and ignore the one inside
See description here: https://pragmaticintegrator.wordpress.com/2010/10/22/using-a-war-module-as-dependency-in-maven/
You would need to add:
So that I could use:
Also it would be nice if you could define the jppf.css and and images/ as maven resources behind a package name and add those resources into the classes folder. You could then mount those resources in your wicket application under your current paths using PackageResourceReferences to serve them from the classpath. This makes embedding easier and I don't have to copy these resources myself then.
We propose to add a number of data elements to the JVM health monitoring:
* peak thread count and total created threads (to be displayed in the same column as the live thread count, i.e. "live / peak / total"
* JVM uptime
Jobs have a [https://www.jppf.org/doc/6.0/index.php?title=Dealing_with_jobs#Non-blocking_jobs blocking job] attribute whose semantic is confusing. Technically, there is no difference between a blocking (.i.e synchronous) and a non-blocking (asynchronous) job. The difference is only in the client code that submits the job (JPPFClient.submitJob() method).
We consider that a job should be submissible either synchronously or asynchronously, regardless of its state
To this effect, we propose to deprecate the '''blocking''' job attribute in JPPFJob, as well as the '''submitJob()''' method in JPPFClient, and add the '''submit(JPPFJob)''' and '''submitAsync(JPPFJob)''' methods to JPPFClient instead, to fullfill the sme functionality.
Also, the deprecated members should '''''not''''' be removed before the next major version (v7.0) or even later, to ensure that users have plenty of advance warnings and the time to adjust their applications. In other words, this should be a long-term deprecation.
Care should also be taken to adapt the J2EE/JCA connector to take this into account.
Since the begining, the docuemntation has been orginazied into multiple .odt documents, grouped via a master (.odm) file. This has notoriously caused problems with cross-document links, in particular in the generated PDF version.
I propose to group all documents into a single one instead, and fix the links.