Reviewing part of the client code, I noticied that the jobDispatched() notfication is sent right after the asynchronous task to send the tasks of a job to the driver is submitted. This means that generally the notification is emitted before the tasks are fully sent to the driver, and contradicts the intended semantics of the notification.
We propose the following additons to the [http://www.jppf.org/doc/5.2/index.php?title=Receiving_the_status_of_tasks_dispatched_to_or_returned_from_the_nodes '''JobTaskListener'''] plugin:
1) Add a new callback method to the listener, called when tasks results are about to be sent back to the client:
2) Add the job SLA and metadata to the available job information in the event:
3) Add the task result to each ServerTaskInformation and enable accessing it as either a stream or a deserialized Task object:
The combination of 1) and 3) will then allow tasks results to be processed even if the client is disconnected before the job completes, provided ''job.getSLA().setCancelUponClientDisconnect(false)'' was set.
The title says it all. In the smae way we made statistics available for the servers, we propose to do the same for the nodes, including the possibility to access them remotely via the management/monitoring API, the ability to register statitics listeners, and the ability to define charts in the admin console
We propose to add timestamps to all statistics updates, along with a creation time for all statitics in the current JVM. We could express the stat update timestamp as the number of nanoseconds since creation, so we could have the best available accuracy, especially since many of the intervals between updates have a sub-milliseconds precision.
When management is dsabed on one or more nodes attached to a server, the server's management API will return an incorrect number of nodes: it reports the number of node with a valid management connection instead of all nodes. This is true for all nbIdleNodes() and nbNodes() of the JPPFDriverAdminMBean interface
I've located the problem in the class NodeSelectionHelper, where the selection/filtering methods have a hasWorkingJmxConnection() condition, which is obviously false when management is disabled on an node. This class was first designed as a helper for the node management forwarding feature, then reused for the driver management methods that count nodes, but I forgot to take into account that nodes can have management disabled.
When, in the client configuration, 2 or more connection pools are defined with different priorities, jobs are not always sent to the pools with the hhighest priority.
There are two scenarios in which this happens:
* when jobs are submitted while the client is initializing, it is possible that at this time only connections with a lower priority are established, in which case they are still considered to be at the highest priority
* when all connections of the pool with the highest priority are busy, they are in fact removed from the idle connections map. This map is a sorted multimap whose key is the priority and value is a collection of connections to a server. When a connection is selected to execute a job, it is removed from the collection, and when the collection is empty, it is removed from the map, which changes the highest priority found in the map. If more jobs are to be executed, they will therefore be sent to connections with don't have the highest priority as defined in the configuration.
From the [http://geronimo.apache.org/ Apache Geronimo] web site, the project appears to be dead: last release, news item and source code commit happened more than 3 years ago. There doesn't seem to be any point in supporting this app server anymore.
Currently, the [http://www.jppf.org/doc/6.0/index.php?title=Transforming_and_encrypting_networked_data data transform feature] is a drain on performance and memory resources since, even when none is defined, it still forces us to read fully each serialized object from the network connection before it can be deserialized. In the same way, each object is fully serialized befored it is sent throw the connection.
Since the same functionality can be accomplished with [http://www.jppf.org/doc/6.0/index.php?title=Composite_serialization composite serialization], we propose to remove the data transformation and replace it with composite serialization. This will allow the code to directly serialize/deserialize to/from the network stream and increase performance while decreqing memory usage.
This implies updating the current "Network Data Encryption" sample to use composite serialization.
When a peer driver notifies its remote peer of a change in its number of nodes and/or threads the remote peer updates the properties of its peer accordingly but does not notify the associated bundler (i.e. load-balancer).
In the case of the "nodethreads" algorithm, this causes a wrong number of total processing threads for the peer driver to be computed, which in turn impairs the efficiency of load-balancing and overall performance of the grid
From this [http://www.jppf.org/forums/index.php/topic,5071.msg12459.html#msg12459 forums post]. We found evidence that Kryo instances cache a mapping of class name to class object, causing class objects from the same class loader to always be used and preventing classes with the same name but from a new class laoder from being used.
Some improvements to the Swing and Web admin console:
* add a "select all" button in the topology view to select all nodes and drivers
* add a "select all jobs" button in the jobs view
* replace the "load balancing" tab with an action in the topology view, based on the driver selected in the tree