We have noted several areas that can be improved preformance-wise, including:
* as shown by profiling drivers and nodes, polling of the default [https://www.jppf.org/doc/6.0/index.php?title=Monitoring_data_providers monitoring data provider] incurs an excessive CPU usage due to the use of com.sun.management.OperatingSystemMXBean for system and process CPU usage
* computation of the persistence identifier for the load-balancer state of each connection is also time-consuming, due to using methods for the discovery of the system's network interfaces and IP addresses. This computation is performed unconditionally, but can be avoided when load-balancer persistence si disabled
* the class [https://github.com/jppf-grid/JPPF/blob/master/common/src/java/org/jppf/utils/NetworkUtils.java NetworkUtils], which discovers the local system's network interfaces and IP addresses, can be improved by caching the IP addresses of the system, and discovering them once and for all at class loading time (static initializer)
From [https://www.jppf.org/forums/index.php/topic,8063.0.html this forums thread].
The constrcutor for org.jppf.execute.AbstractExecutionManager is as follows:
The problem here is in the statement "poolSize = JPPFConfiguration.get(nbThreadsProperty);", which uses the global configuration instead of the config for the JPPF component (client or node) which initializes the execution manger.
Instead, the constructor should have the following signature:
We propose to implement a DSL and asociated API for expressing job selectors in a way similar to what we have for [https://www.jppf.org/doc/6.2/index.php?title=Execution_Policies execution policies]. This will significantly improve the expressiveness of job selectors, without having to resort to [https://www.jppf.org/doc/6.2/index.php?title=Server_management#Scripted_job_selector scripted job selectors] for complex selection functions.
This DSL would include a number of predicates and operators:
* boolean predicates: and, or, xor, not
* comparison operators for Comparable metadata values: ==, !=, <, <=, >, >=, between (including or excluding upper and lower bounds)
* contains, one of, regex matching
* any other predicate that we migth find useful or convenient
The attached dependency-check report lists a number of vulnerabilities in the PPF dependencies. So far, all vulnerabilities are found in the web admin console and tied to wicket. We will need to upgrade the version of Apache Wicket to 8.x (currently 7.4.0), which was overdue anyway
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 126.96.36.199 First sentence. eligble channels sould be eligible channels
- chapter 188.8.131.52 Second word should be each, not aach
- chapter 184.108.40.206, 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 220.127.116.11 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 18.104.22.168.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.