We propose to implement a set of facilities to provide easy access to one or more databases from a JPPF application. One goal will be to make it as painless as possible to define, cache and use JDBC data sources using a simple API.
Some important considerations:
'''1) choice of a connection pool/datasource implementation''': we propose [https://github.com/brettwooldridge/HikariCP '''HikariCP''']. It has great performance, it is small (131 kb jar) and has no runtime dependency other than SLF4J which is already distributed with JPPF
'''2) how to define datasources''': we propose to do this from the JPPF configuration, for instance:
* '''configId''' is used to distinguish the datasource properties when multiple datasources are defined
* the datasource '''name''' is mandatory and is used to store and retrieve the datasource in a custom registry. It is also the datasource name used in the configuration of this job persistence implementation
* '''hikaricp_property_x''' designates any valid HikariCP configuration property. Properties not supported by HikariCP are simply ignored
'''3) scope and class loading considerations''': we want to be able to define, in a single place, datasources that will be instantiated in every node. To achieve that, we want to be able to create the definitions on the driver side and use the built-in distributed class loader to download them and make the JDBC driver classes available to the nodes, without deploying them in each node. We propose implementing a "datasource provider" discovered via SPI, with a different implementation in the driver. Each datasource configuration could also specify a "scope" property only used n the driver, to tell whether the datasource is to be deployed on the nodes (scope = node) or in the local JVM
This feature will also be used by the feature request JPPF-480, for a built-in dabase implementation of job persistence
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.