JPPF Issue Tracker
JPPF (jppf)
December 09, 2018
feature_request_tiny.png 09:17  Feature request JPPF-566 - New sample: embedded grid
lolocohen : Issue closed
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 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 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 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 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'''].
November 20, 2018
feature_request_tiny.png 14:20  Feature request JPPF-549 - Asynchonous communication between server and client
lolocohen : Issue closed
November 19, 2018
bug_report_tiny.png 10:29  Bug report JPPF-560 - org.jppf.utils.collections.ConcurrentHashSet.add() return value does not follow java.util.Set API
lolocohen : Issue closed
November 18, 2018
bug_report_tiny.png 21:11  Bug report JPPF-560 - org.jppf.utils.collections.ConcurrentHashSet.add() return value does not follow java.util.Set API
rtordoff : Issue created
The org.jppf.utils.collections.ConcurrentHashSet add() method does not follow the [https://docs.oracle.com/javase/7/docs/api/java/util/Set.html#add(E) java.util.Set] API which states:

> Returns:
> true if this set did not already contain the specified element

The ConcurentHashSet implementation is doing the opposite and returning false when the Set does not already contain the element, and returns true when the Set already contains the item being added.
task_tiny.png 14:35  Task JPPF-559 - Explore the possibilities for job streaming
lolocohen : Issue created
JPPF currently has a very basic [https://www.jppf.org/doc/6.1/index.php?title=Submitting_multiple_jobs_concurrently#Job_streaming '''API for job streaming''']. However, ths is wholly insufficient for real stream processing, as many things are missing which have to be implemented by the users in an ad-hoc manner:
* ability to plug-in stream data sources (from files, databases, event-based systems, etc.)
* stateful computations over streams of data (aggregates, analytics, etc.)
* map/reduce capabilities
* ... ?
We propose to explore what can be done in that area. Some ideas that popped into my (tiny) head:
* make the job's [https://www.jppf.org/doc/6.1/index.php?title=Sharing_data_among_tasks_:_the_DataProvider_API '''data provider'''] read-write instead of read-only, so as to provide state at the job level instead of only at the task level. We could then associate a merge strategy / reducer to each job. The data provider seems a good candidate, as opposed to the job metadata, because it is loaded the same class loader as the tasks.
* provide a common API for various sources of straming data and plug them into a job sream
November 15, 2018
feature_request_tiny.png 06:24  Feature request JPPF-558 - Node provisioning notifications
lolocohen : Issue created
We propose to add the ability for master nodes to emit JMX notifications upon provisioning events, whenever a slave node starts or stops.
November 11, 2018
bug_report_tiny.png 09:22  Bug report JPPF-557 - JPPF node with Xstream serialization.
lolocohen : Issue closed
November 07, 2018
bug_report_tiny.png 14:04  Bug report JPPF-557 - JPPF node with Xstream serialization.
ecx_q : Issue created
JPPF node with Xstream serialization fails to connect to JPPF driver. The following exception occurs:

2018-11-07 12:47:58,204 [DEBUG][org.jppf.node.NodeRunner.main(152)]: received reconnection notification : org.jppf.JPPFNodeReconnectionNotification: Could not reconnect to the server
at org.jppf.classloader.AbstractJPPFClassLoaderLifeCycle.init(AbstractJPPFClassLoaderLifeCycle.java:130)
at org.jppf.classloader.JPPFClassLoader.(JPPFClassLoader.java:41)
at org.jppf.node.NodeRunner$2.run(NodeRunner.java:264)
at org.jppf.node.NodeRunner$2.run(NodeRunner.java:261)
at java.security.AccessController.doPrivileged(Native Method)
at org.jppf.node.NodeRunner.getJPPFClassLoader(NodeRunner.java:267)
at org.jppf.node.NodeRunner.createNode(NodeRunner.java:200)
at org.jppf.node.NodeRunner.main(NodeRunner.java:147)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 0
at org.jppf.classloader.RemoteClassLoaderConnection.performHandshake(RemoteClassLoaderConnection.java:127)
at org.jppf.classloader.RemoteClassLoaderConnection.init(RemoteClassLoaderConnection.java:87)
at org.jppf.classloader.AbstractJPPFClassLoaderLifeCycle.init(AbstractJPPFClassLoaderLifeCycle.java:128)
... 7 more
Caused by: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 0
at org.jppf.classloader.AbstractClassLoaderConnection.performCommonHandshake(AbstractClassLoaderConnection.java:79)
at org.jppf.classloader.RemoteClassLoaderConnection.performHandshake(RemoteClassLoaderConnection.java:123)
... 9 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.jppf.io.MultipleBuffersLocation.(MultipleBuffersLocation.java:78)
at org.jppf.io.IOHelper.serializeDataToMemory(IOHelper.java:275)
at org.jppf.io.IOHelper.serializeData(IOHelper.java:255)
at org.jppf.io.IOHelper.sendData(IOHelper.java:217)
at org.jppf.classloader.RemoteResourceRequest.run(RemoteResourceRequest.java:69)
at org.jppf.classloader.AbstractClassLoaderConnection.performCommonHandshake(AbstractClassLoaderConnection.java:66)
... 10 more
October 30, 2018
bug_report_tiny.png 22:44  Bug report JPPF-556 - DefaultJPPFSerialization fails to serialize JPPF task execution notification
lolocohen : Issue closed
bug_report_tiny.png 13:28  Bug report JPPF-556 - DefaultJPPFSerialization fails to serialize JPPF task execution notification
ecx_q : Issue created
DefaultJPPFSerialization fails to serialize JPPF task execution notification, throws java.io.IOException: Can not set boolean field org.jppf.management.OffloadableNotification.userDataOffloaded to javax.management.ObjectName.
The problem can lead to unexpected task cancellations in case, when DefaultJPPFSerialization is used.
enhancement_tiny.png 09:51  Enhancement JPPF-552 - Improve job API to enable tasks as lambdas
lolocohen : Issue closed
October 29, 2018
bug_report_tiny.png 21:58  Bug report JPPF-555 - No argument checking in execution policies constructors
lolocohen : Issue closed
October 20, 2018
feature_request_tiny.png 06:01  Feature request JPPF-548 - Drop support for JDK 7 and switch to JDK 8 or later
lolocohen : Issue closed
feature_request_tiny.png 05:59  Feature request JPPF-554 - AcceptAll, RejectAll execution policy
lolocohen : Issue closed
bug_report_tiny.png 05:37  Bug report JPPF-555 - No argument checking in execution policies constructors
lolocohen : Issue created
The constructors of the various execution policy rules perform no argument checking in their constructors. This is inconsistent with the execution policy XML schema and makes usage of the API a potential problem because default values are used for null or missing arguments.

Missing checks I have identified so far:
* null checks
* min/max number of arguments (e.g. AND rule should have at least 2 non-null arguments)
October 18, 2018
feature_request_tiny.png 09:52  Feature request JPPF-551 - Possibility to setup default execution policy in jppf client config
lolocohen : Issue closed
October 15, 2018
feature_request_tiny.png 10:13  Feature request JPPF-554 - AcceptAll, RejectAll execution policy
zorba128 : Issue created
To simplify execution policy customization it would be nice if there were "AcceptAll" and "RejectAll" execution policies available.
Or simply "empty" but then it is non-obvious if if accepts or rejects everything.
These are useful for eg. disabling parts of rule "and(config, rejectAll)" / "or(config/ acceptAll)".

marcin

bug_report_tiny.png 04:47  Bug report JPPF-553 - Configuration documentation demo still uses HTTP urls
lolocohen : Issue closed
bug_report_tiny.png 04:45  Bug report JPPF-550 - log4j dependency in jppf.commons
lolocohen : Issue closed
bug_report_tiny.png 04:07  Bug report JPPF-553 - Configuration documentation demo still uses HTTP urls
lolocohen : Issue created
In the "Configuration documentation" generator demo, the generated HTML page uses http links for the stylesheet and favicon:


This causes problems when viewed from the JPPF web site: some styles are lost, due to non-safe https-to http links (the browser does not load the stylesheet).
October 13, 2018
enhancement_tiny.png 10:17  Enhancement JPPF-552 - Improve job API to enable tasks as lambdas
lolocohen : Issue created
We propose to add APIs to the JPPFJob class, in order to allow tasks as lambda expressions.

For example, for Callable and Runnable tasks:
public Task addRunnable(JPPFRunnableTask task);

public Task addCallable(JPPFCallable task);
where JPPFRunnableTask is defined as:
public class JPPFRunnableTask extends Runnable, Serializable { }
and JPPFCallable is defined as:
public class JPPFCallable extends Callable, Serializable { }
We need to ensure the tasks are serializable.

We could then add a callable task as a lambda expression, such as:
JPPFJob job = new JPPFJob();
job.addCallable(() -> "hello, world");
October 11, 2018
feature_request_tiny.png 11:23  Feature request JPPF-551 - Possibility to setup default execution policy in jppf client config
zorba128 : Issue created
Provide jppf.properties configuration option to setup default execution policy for newly created jobs, something similar to:
jppf.jobSLA.defaultPolicy = "jppf.policy.xml"
jppf.jobSLA.defaultPolicy.javascript = "return true"
it might support inline policy or loading policy from external file
October 08, 2018
bug_report_tiny.png 15:26  Bug report JPPF-550 - log4j dependency in jppf.commons
zorba128 : Issue created
When trying to use JPPF client library log4j gets sucked into project by transitive dependencies.

Rather than that - jppf client (or - to be more specific - jppf commons) should depend on slf4j api only, leaving decision of which logger binding to use to client application.

So from dependencies below all but first should be removed.


org.slf4j
slf4j-api
1.7.25


org.slf4j
slf4j-log4j12
1.7.25
runtime


log4j
log4j
1.2.15
runtime

If node/driver/web ui/admin ui want to use log4j for logging - it should become their runtime dependency.
October 07, 2018
feature_request_tiny.png 07:50  Feature request JPPF-549 - Asynchonous communication between server and client
lolocohen : Issue created
Currently, the communication between JPPF servers and client is based on a synchronous request/response model. As a consequence, a connection can only handle a single job at a time. This can impair the scalability of JPPF applications.

We propose to switch to an asynchronous model where each connection can handle multiple jobs, removing or mitigating the need for multiple connections.
feature_request_tiny.png 07:35  Feature request JPPF-548 - Drop support for JDK 7 and switch to JDK 8 or later
lolocohen : Issue created
JPPF 6.1 will stop supporting Java 7, whose end-of-life happened a long time ago.
The first step will be to make the compilation, build and tests pass without errors or warnings.
Usage of Java 8 new features and APIs will be either progressive, while writing new code or updating existing code, or systematic in some cases if we determine that the benefits are worth it.

The first difficulty will be to refactor or rewrite the custom doclet code we use for the @exclude tag used in the javadoc.
October 06, 2018
icon_build.png 13:00 JPPF 6.0
New version released
feature_request_tiny.png 10:24  Feature request JPPF-528 - Restructuring of and major improvements to the documentation
lolocohen : Issue closed
September 26, 2018
enhancement_tiny.png 07:06  Enhancement JPPF-547 - Improvements to the handling of jobs classpath
lolocohen : Issue closed
September 17, 2018
feature_request_tiny.png 06:23  Feature request JPPF-546 - Use ScriptScriptDefinition objects wherever JSR 223 compliant scripts are used
lolocohen : Issue closed
September 13, 2018
enhancement_tiny.png 09:04  Enhancement JPPF-547 - Improvements to the handling of jobs classpath
lolocohen : Issue created
The SLA of each JPPF job has a classpath attribute which allows the job to transport a set of jar files to dynamically add to its classloader when it is executed on a node.

There are currently a number of problems with the classpath itself and with the way it is handled by the node:
* classpath elements refer to a "local" and a "remote" location. The semantics here is confusing and we propose to use "source" and "target" locations instead
* there is currently no way to avoid downloading jar files if they already exists on the file system. We should allow a flow to allow it, make it default to false to preserve the existing behavior as a default
* the notion of "force classloader reset" isn't clear ly explained and does not work as documented. This shouid be fixed
September 10, 2018
feature_request_tiny.png 08:09  Feature request JPPF-546 - Use ScriptScriptDefinition objects wherever JSR 223 compliant scripts are used
lolocohen : Issue created
Many JPPF classes use JSR 223-compliant scripts to perform their functionality:
* scripted tasks
* scripted execution policies
* scripted node selectors
* scripted job selectors
* scripted validation function in ClassPathElementImpl
We propose to introduce a new class ScriptDefinition which groups the attributes needed to execute the scripts:
* language: the scripting language, e.g. "javascript", "groovy"
* script: the actual script content as text
* bindings: an optional set of variable bindings made available to the script
* reusableId: an optional identifier for the script which allows reusing the compiled form of the script so as to avoid uncessary recompilation of the script
One of the objectives is to simplify the code that uses scripts, in particular so as to hide the internal mechanism to cache and pool the scripting engines and reusable compiled scripts.
A longer-term objective (targetting JPPF v6.1) is to expose the ScriptDefinition class wherever scripts are used in the public APIs. This will simplify the exposed APIs while increasing flexibility and add consistency with regards to scripting.
Show moreaction_add_small.png