Referring to the Snippet in [http://www.jppf.org/forums/index.php?topic=748.0] i made up a Task wich is using [https://github.com/brettwooldridge/HikariCP HikariCP] as ConnectionPool.
When start the Client code everything is fine. But when i want to start it again i get following Output:
Maybe the Classloader of the Node gets the bytecode a second time and isnt able to cast the "old" stored object into the new pulled Class?
The main goal is to made up a connectionpool on a node and let the task on the node do something on the database with different clients.
Currently there is too much complexity in the handling of client connections to the drivers and their status. In particular, each JPPFClientConnection implementation holds 2 actual connections, both subclasses of AbstractClientConnectionHandler and each with their status listeners. The main connection status is set either directly or as a combination of the states of the two "sub-connections". In the former case, the sub-connections status becomes inconsistent with that of the main connection.
Overall, this complexity results in many observed problems in the client, especially when running the automated tests: deadlocks, race conditions, failures of the recovery and failover mechanisms.
What we propose is to remove the code that handle the status in the sub-connections (and thus in AbstractClientConnectionHandler) and only keep one source of status and associated events.
Additionally, the abstract class org.jppf.client.balancer.ChannelWrapper, subclassed as ChannelWrapperLocal and ChannelWrapperRemote, holds an executor filed of type ExecutorService defined as a single thread executor in both subclasses. Instead of a separate thread pool for each ChannelWrapper, we should make use of the executor held by the JPPFClient instance, and add proper synchronization if needed.
To have the JPPF logging working in JBoss 7 and Wildfly deployments of the J2EE connector, the dependency on slf4j must be declared in the MANIFEST.MF with the attribute "'''Dependencies: org.slf4j,org.slf4j.impl'''". Also the sfa4 and log4j jars should be removed from the JPPF rar file, since the logging api are provided by JBOss as OSGi dependencies.
The J2EE connector build sdhoud be modified to reflect this.
Then, the JBoss/Wildfly logging configuration can be modified, for instance like this:
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