We need to fix a number of user-reported errors in the documentation:
- chapter 2.5.2, here under "Job SLA":
nuumber should be number
- chapter 3.4.2 Remove one "the" in the sentence:
In other words, the results are always in the same order as the tasks in the the job.
- chapter 4.1.12 There is a "r" missing in the word "interruptible" in the sentence:
Tasks that do not extend AbstractTask, such as Callable, Runnable, Pojo tasks or tasks annotated with @JPPFRunnable, will need to implement the Interruptibility interface to override the interuptible flag, as in this example:
- chapter 4.4, the yellow box, under Note 2
There is a space missing after the comma: from each task's perspective,the data provider
- chapter 220.127.116.11 First sentence. eligble channels sould be eligible channels
- chapter 18.104.22.168 Second word should be each, not aach
- chapter 22.214.171.124, the yellow box, Note 1:
usally should be usually
- chapter 4.9.1, third word:
heirarchy should be hierarchy
- chapter 4.11, yellow box:
hanldle should be handle
- chapter 126.96.36.199 THe text block under the source:
overriden should be overridden
- chapter 4.12 delete one the" in the sentence:
extensions to the the job SLA specifying if and how the persistence of each job should be handled
- chapter 5.4.1, yellow box, note 2: explicitely should be explicitly
- chapter 5.4.5 ollload schould be offload, attahed should ne attached
- chapter 188.8.131.52.3 exppressed should be expressed, expressd should be expressed
We propose to add security scans as part of the JPPF build, including:
* dependency checks (with [https://jeremylong.github.io/DependencyCheck/dependency-check-ant/index.html dependency-check for Ant])
* Docker images scans (maybe [https://github.com/coreos/clair/blob/master/Documentation/running-clair.md Clair]?)
Currently, the full suite of autmated tests take 15 to 25 mn to run, depending on the hardware. We propose to reduce it to a more reasonable set of tests that would take much less time, while still providing a meaningful coverage.
We also propose to run this lightweight suite as part of the Travis build setup in github, in addition to making it available locally on the command line. The currentm CI build with Jenkins would still run the full suite.
The Jenkins build is showing intermittent failures for some of our automated tests on multiserver topologies. I'm not sure yet what the problem is exactly, but it seems to occur frequently enough (1 time out of 5) to warrant a dedicated bug report.
The failures I've been seeing recently, and for which a set of logs is attached to this defect:
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.
Antoher objectivve is to provide ready-to-use tools and configurations to run JPPF grids within a Docker swarm/Kubernetes infrastructure.
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