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
The [https://github.com/jppf-grid/JPPF/blob/master/common/src/java/org/jppf/process/ProcessLauncher.java ProcessLauncher] class is used to launch drivers and nodes and allows them to be restarted remotely. We have found [https://github.com/jppf-grid/JPPF/blob/master/common/src/java/org/jppf/process/ProcessLauncher.java#L176 here] that it always sets the "log4j.configuration" system property, even if the value of the property is null, which may happen if another logging framework is used. This results in an error being printed at startup.
When the driver is under stress, I sometimes see the following exception:
This happens because the method "AsyncNodeMessageHandler.bundleSent()" is called just after a job dispatch is sent to a node, but it is possible, if the tasks are very short-lived, that the results have already been received and processed, leading to the NPE
In high load scenarios where massive amounts of [https://www.jppf.org/doc/6.2/index.php?title=Driver_management_and_monitoring#Job_notifications job life cycle notifications] are generated, I observed the following issues:
* on the server side, the notifications tend to accumulate in queues associated with the client connections, leading to large increases in heap usage, even OOMEs if the JPPF driver's heap is not large enough. This is not a memory leak, but rather a large spike in heap usage.
* on the client side (e.g. the admin console configured with immediate notifications mode), the notification handling will use a separate thread for each notification, leading to threads proliferation (I observed cases with a peak of over 30,000 live threads), leading in turn to the process being completely frozen
Currently, the only way to know the data that is provided by the [https://www.jppf.org/doc/6.2/index.php?title=Monitoring_data_providers monitoring data providers] is to obtain a [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/management/diagnostics/HealthSnapshot.html HealthSnapshot] and call its ''getProperties()'' method. However, this only provides the names and values of the data, but does not provide important metadata such as the type of value (int, String, etc.) or the default value.
We propose to add one or more methods to the [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/management/diagnostics/DiagnosticsMBean.html DiagnosticsMBean] interface to obtain a collection of the provided properties as [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/utils/configuration/JPPFProperty.html JPPFProperty] objects, for instance:
The main (and probably only) issue I have with [http://www.jfree.org/jfreechart/ JFreeChart] is its licensing, LGPL 2.1. [https://github.com/knowm/XChart XChart], on the other hand, is licensed under ASL 2.0, the same as for JPPF.