JPPF Issue Tracker
JPPF (jppf)
December 11, 2018
feature_request_tiny.png 07:54  Feature request JPPF-564 - Asynchronous communication betwen node and driver
lolocohen : Assignee changed: lolo4j
December 09, 2018
task_tiny.png 09:22  Task JPPF-565 - Feature removals
lolocohen : Description updated
feature_request_tiny.png 09:17  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Issue closed
feature_request_tiny.png 09:17  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Status changed: New ⇒ Closed
feature_request_tiny.png 09:17  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Resolution changed: Not determined ⇒ RESOLVED
feature_request_tiny.png 09:17  Feature request JPPF-566 - New sample: embedded grid
lolocohen : lolo4j ⇒ Not being worked on
feature_request_tiny.png 06:08  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Description updated
feature_request_tiny.png 06:07  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : Issue closed
feature_request_tiny.png 06:07  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : Status changed: New ⇒ Closed
feature_request_tiny.png 06:07  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : Resolution changed: Not determined ⇒ RESOLVED
feature_request_tiny.png 06:07  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : lolo4j ⇒ Not being worked on
feature_request_tiny.png 05:38  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Description updated
feature_request_tiny.png 05:38  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Assignee changed: lolo4j
feature_request_tiny.png 05:36  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Issue created
Following feature request JPPF-563, create a new sample in the samples pack which demonstrates how to start a driver, node and client programmatically, all embedded within the same JVM. The sample will show the following functionalities:
* embedded driver life cycle: create, start, stop
* embedded node life cycle: create, start, stop
* connecting a client and submitting a job
* programmatically creating the configuration for a driver, node and client
* using management and monitoring APIs for an embedded driver and node
December 05, 2018
task_tiny.png 08:15  Task JPPF-565 - Feature removals
lolocohen : Description updated
task_tiny.png 07:21  Task JPPF-565 - Feature removals
lolocohen : Target milestone changed: Not determined ⇒ JPPF 6.1
task_tiny.png 07:18  Task JPPF-565 - Feature removals
lolocohen : Description updated
task_tiny.png 07:18  Task JPPF-565 - Feature removals
lolocohen : Assignee changed: lolo4j
task_tiny.png 07:16  Task JPPF-565 - Feature removals
lolocohen : Issue created
We propose that the following features be either deprecated or dropped altogether:

'''1. .Net integration'''

This feature relies heavily on the [http://jni4net.com/ '''jni4net'''] framework, which hasn't seen a new version in 4 years. Following the switch to Java 8 (feature request JPPF-548), its .Net proxy generator is no longer fully working, as it doesn't handle new Java 8 constucts such as default methods in interfaces, It is currently not possible to build it with the current code, and I don't see any solution that can be mainained in the long term. I propose to drop this feature from JPPF 6.1 forward. We will still maintain it for prior versiosn.

'''2. Android integration'''

The switch to Java 8 requires a lot of changes to the Android port, including, but definitely not limited to, the min Android sdk version and build tools. I haven't evaluated the changes that need to be done to the code itself, and, given the lack of bandwith (I'm just 1 developer), I tend to think it should be dropped so we can focus on more modern features such as job streaming and big data. If anyone volunteers to take this feature on, I'll be happy to assist in any way, In any case, we'll keep maintaining it for versions up to 6.0.

'''3. Persistent data in NodeRunner'''

The [https://www.jppf.org/javadoc/6.1/index.html?org/jppf/node/NodeRunner.html '''NodeRunner'''] class provides 3 methods '''setPersistentData()''', '''getPersistentData()''' and '''removePersistentData()''', which were intended for tasks to be able to store, access and manage data on the nodes accross job executions. These methods are inherently dangerous, because they can cause the nodes to retain objects and classes from many different class loaders, resulting in class loader leaks and potential out-of-memory conditions. This feature isn't used anymore in the JPPF code, and I believe now's a good time to remove it.

'''4. Node security policy'''

I can no longer see the benefit of the [https://www.jppf.org/doc/6.0/index.php?title=Node_configuration#Security_policy '''security policy'''] in the node configuration. We haven't touched this code in years, the default node security policy in the node distribution is no longer close to being useful or even accurate, and this can be easily replaced with a standard SecurityManager and associated security policy file. This feature should definitely be removed.
November 29, 2018
feature_request_tiny.png 08:54  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : Assignee changed: lolo4j
November 27, 2018
feature_request_tiny.png 09:02  Feature request JPPF-564 - Asynchronous communication betwen node and driver
lolocohen : Issue created
Similarly to feature request JPPF-549, we propose to refactor the communication between divers nd nodes and make it possible for a node to handle multiple jobs concurrently.

We can also explore the possibility for a node to connect to multiple drivers?
feature_request_tiny.png 08:55  Feature request JPPF-563 - Make the JPPF driver and node not singletons
lolocohen : Issue created
Current the [https://www.jppf.org/javadoc/6.1/index.html?org/jppf/server/JPPFDriver.html '''JPPFDriver'''] is implemented as a singleton. This means there can be only one per JVM. The same is true for the nodes, whether local to the driver's JVM or remote.

We propose to change that and make it possible to have any number of drivers and/or nodes per JVM. They might have the possibility to share some common resources, for example the NIO thread pool.
feature_request_tiny.png 07:26  Feature request JPPF-562 - Fix the preference execution policy
lolocohen : Issue created
Currently the [https://www.jppf.org/doc/6.1/index.php?title=Execution_Policy_Elements#Preference '''Preference'''] execution poliy is applied to each node individually and is identical to the [https://www.jppf.org/doc/6.1/index.php?title=Execution_Policy_Elements#OR '''OR'''] execution policy. To sum up: despite its name, it has nothing to do with a "preference".

We propose to make it live up to its name, which implies:

* it should define a real order of preference for a number of node execution policies, where a node that satisfies policy N in the list will have priority over a node that satisfies policy N + 1
* it should be applied globally to all the nodes available to the driver
* because of the previous point, it should be a separate attribute of the job SLA
* it should be applicable to the client-side as well, where it would define a driver preference rather than a node preference
* special care should be taken about perfomance, as the algorithm will be in O(nbNodes * nbJobs). Should we allow parallel (with regards to the nodes) evaluation of the policy for each job?
November 24, 2018
icon_build.png 14:00 JPPF 6.0.1
New version released
icon_build.png 14:00 JPPF 5.2.10
New version released
icon_build.png 14:00 JPPF 5.1.7
New version released
November 23, 2018
bug_report_tiny.png 07:52  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : Issue closed
bug_report_tiny.png 07:52  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : Status changed: New ⇒ Closed
bug_report_tiny.png 07:52  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : Resolution changed: Not determined ⇒ RESOLVED
bug_report_tiny.png 07:52  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : lolo4j ⇒ Not being worked on
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : Assignee changed: lolo4j
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF trunk' confirmed
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.1.6' confirmed
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.2.9' confirmed
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 6.0' confirmed
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF trunk' added
bug_report_tiny.png 05:46  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.1.6' added
bug_report_tiny.png 05:45  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.1.5' removed
bug_report_tiny.png 05:45  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.2.9' added
bug_report_tiny.png 05:44  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 5.1.5' added
bug_report_tiny.png 05:41  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : Issue created
After seeing one failure of the TestJPPFUuid unit test (the only one I've seen in years), I performed some more rigorous testing of the uuids generated by [https://github.com/jppf-grid/JPPF/blob/master/common/src/java/org/jppf/utils/JPPFUuid.java '''JPPFUuid''']. I found that there is around 1 collision for every 40 million (40,000,000) uuids. Essentially, this is due to the use of a non cryptographically strong random number generator, namely [https://docs.oracle.com/javase/8/docs/api/index.html?java/util/Random.html '''java.util.Random''']. Instead, we should use [https://docs.oracle.com/javase/8/docs/api/index.html?java/security/SecureRandom.html '''java.security.SecureRandom'''].
bug_report_tiny.png 05:41  Bug report JPPF-561 - JPPFUuid generates uuid collisions
lolocohen : 'JPPF 6.0' added
November 20, 2018
task_tiny.png 14:21  Task JPPF-559 - Explore the possibilities for job streaming
lolocohen : Assignee changed: lolo4j
October 06, 2018
icon_build.png 13:00 JPPF 6.0
New version released
August 04, 2018
icon_milestone.png 22:19 JPPF 5.2.9
A new milestone has been reached
August 01, 2018
icon_milestone.png 22:00 JPPF 4.0
A new milestone has been reached
July 21, 2018
icon_milestone.png 18:43 JPPF 5.2.2
A new milestone has been reached
icon_milestone.png 18:07 JPPF 5.1.6
A new milestone has been reached
icon_milestone.png 12:23 JPPF 5.2.5
A new milestone has been reached
icon_milestone.png 11:22 JPPF 5.2.1
A new milestone has been reached
icon_milestone.png 10:59 JPPF 2.5.5
A new milestone has been reached
icon_milestone.png 10:33 JPPF 5.1.2
A new milestone has been reached
icon_milestone.png 10:09 JPPF 5.1.7
A new milestone has been reached
icon_milestone.png 09:46 JPPF 5.2.7
A new milestone has been reached
Show moreaction_add_small.png