JPPF Issue Tracker
JPPF (jppf)
January 26, 2020
feature_request_tiny.png 10:59  Feature request JPPF-371 - New sample to upgrade Windows nodes to .Net-capable status
lolocohen : Issue closed
January 24, 2020
icon_milestone.png 19:45 JPPF 6.1.3
A new milestone has been reached
icon_milestone.png 10:50 JPPF 3.3
A new milestone has been reached
icon_milestone.png 10:49 JPPF 5.1
A new milestone has been reached
icon_milestone.png 10:47 JPPF 6.0
A new milestone has been reached
icon_milestone.png 10:40 JPPF 6.0.2
A new milestone has been reached
icon_milestone.png 10:37 JPPF 2.5.5
A new milestone has been reached
icon_milestone.png 10:30 JPPF 5.2.8
A new milestone has been reached
January 21, 2020
icon_milestone.png 14:38 JPPF 4.0
A new milestone has been reached
January 17, 2020
bug_report_tiny.png 08:12  Bug report JPPF-615 - ProcessLauncher should not explicitely rely on Log4j for logging
lolocohen : Issue closed
January 16, 2020
bug_report_tiny.png 09:46  Bug report JPPF-616 - Build broken due to Maven central switching to HTTPS only
lolocohen : Issue closed
bug_report_tiny.png 07:34  Bug report JPPF-616 - Build broken due to Maven central switching to HTTPS only
lolocohen : Issue created
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
January 15, 2020
icon_milestone.png 22:27 JPPF 5.2.5
A new milestone has been reached
icon_milestone.png 21:06 JPPF 5.2.9
A new milestone has been reached
icon_milestone.png 20:49 JPPF 5.2.7
A new milestone has been reached
icon_milestone.png 19:22 JPPF 5.2.4
A new milestone has been reached
icon_milestone.png 19:20 JPPF 3.2
A new milestone has been reached
icon_milestone.png 19:20 JPPF 4.1
A new milestone has been reached
icon_milestone.png 19:14 JPPF 5.2.2
A new milestone has been reached
icon_milestone.png 19:13 JPPF 5.2
A new milestone has been reached
icon_milestone.png 19:12 JPPF 5.2.1
A new milestone has been reached
icon_milestone.png 08:57 JPPF 4.2
A new milestone has been reached
January 10, 2020
bug_report_tiny.png 08:45  Bug report JPPF-615 - ProcessLauncher should not explicitely rely on Log4j for logging
lolocohen : Issue created
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.
January 04, 2020
bug_report_tiny.png 12:04  Bug report JPPF-614 - Race condition in the client prevents job recovery upon disconnection
lolocohen : Issue closed
bug_report_tiny.png 10:35  Bug report JPPF-614 - Race condition in the client prevents job recovery upon disconnection
lolocohen : Issue created
Sometimes a job that is executing is not recovered when the client gets disconnected from the driver.
January 02, 2020
icon_milestone.png 19:34 JPPF 6.1.4
A new milestone has been reached
icon_milestone.png 17:21 JPPF 6.0.5
A new milestone has been reached
December 21, 2019
icon_build.png 08:00 JPPF 6.1.4
New version released
December 20, 2019
enhancement_tiny.png 10:15  Enhancement JPPF-610 - Add an API to instrospect the properties defined in the monitoring data providers
lolocohen : Issue closed
December 19, 2019
bug_report_tiny.png 09:28  Bug report JPPF-613 - NPE due to race condition in the server leads to losing node connections
lolocohen : Issue closed
bug_report_tiny.png 08:41  Bug report JPPF-613 - NPE due to race condition in the server leads to losing node connections
lolocohen : Issue created
When the driver is under stress, I sometimes see the following exception:
java.lang.NullPointerException
at org.jppf.server.nio.nodeserver.async.AsyncNodeMessageHandler.bundleSent(AsyncNodeMessageHandler.java:111)
at org.jppf.server.nio.nodeserver.async.AsyncNodeMessageWriter.postWrite(AsyncNodeMessageWriter.java:67)
at org.jppf.server.nio.nodeserver.async.AsyncNodeMessageWriter.postWrite(AsyncNodeMessageWriter.java:1)
at org.jppf.nio.NioMessageWriter.doWrite(NioMessageWriter.java:72)
at org.jppf.nio.NioMessageWriter.write(NioMessageWriter.java:52)
at org.jppf.nio.StatelessNioServer.handleWrite(StatelessNioServer.java:263)
at org.jppf.nio.StatelessNioServer.lambda$2(StatelessNioServer.java:104)
at org.jppf.nio.StatelessNioServer$KeysetHandler.handle(StatelessNioServer.java:225)
at org.jppf.nio.StatelessNioServer.lambda$3(StatelessNioServer.java:195)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
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
December 18, 2019
enhancement_tiny.png 01:30  Enhancement JPPF-611 - Document the values limits and validity in the constructors of JPPFSchedule
lolocohen : Issue closed
bug_report_tiny.png 01:12  Bug report JPPF-605 - Investigate the performance of the monitoring APIs and administration console
lolocohen : Issue closed
bug_report_tiny.png 01:12  Bug report JPPF-612 - JMX remote connector: poor handling of large number of notifications
lolocohen : Issue closed
bug_report_tiny.png 00:47  Bug report JPPF-612 - JMX remote connector: poor handling of large number of notifications
lolocohen : Issue created
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
December 06, 2019
task_tiny.png 07:31  Task JPPF-609 - Explore the possibility to replace JFreeChart with XChart in the admin console
lolocohen : Issue closed
December 03, 2019
enhancement_tiny.png 07:04  Enhancement JPPF-611 - Document the values limits and validity in the constructors of JPPFSchedule
lolocohen : Issue created
The constructor JPPFSchedule(long millis) does not specify what happens when you specify 0 or less. This can lead to misinterpretation of the resulting behavior. For instance, the following code:
Task task = ...;
task.setTimeoutSchedule(new JPPFSchedule(0));
means that the task will expire immediately, however a value of 0 or less for the timeout could also mean that it never expires. This needs to be clarified in the kavadoc of JPPFSchedule
November 27, 2019
feature_request_tiny.png 07:40  Feature request JPPF-607 - Reorganize the documentation on management and monitoring
lolocohen : Issue closed
November 20, 2019
enhancement_tiny.png 22:28  Enhancement JPPF-610 - Add an API to instrospect the properties defined in the monitoring data providers
lolocohen : Issue created
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:
public interface DiagnosticsMBean {
List> getMonitoringDataDefinitions();
}
November 17, 2019
task_tiny.png 09:56  Task JPPF-609 - Explore the possibility to replace JFreeChart with XChart in the admin console
lolocohen : Issue created
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.
Show moreaction_add_small.png