5 Replies Latest reply on Aug 31, 2017 9:17 AM by rareddy

Resource adapter based on Java Native Interface

tomesc Aug 30, 2017 10:33 AM

My custom resource adapter is using JNI to comunicate with the EIS. The JNI wraps a plain C-function to send and receive data (usually commands like open, find, read, etc.). E.g. a SQL-Select has to be translated to a sequence of commands, starting with a find, following by reads and finishing by a close command. All works fine as long as it is used by one client only. Otherwise the commands of the concurrent sessions do interrupt each other. I am quit sure it depends on the EIS which establishes only one (low level) connection per (client) process (or loaded JNI library), in this case the JVM. Thus I'd have to install one server per client, what I do not want actually.

Has someone experience with that behaviour and could give some advice or hint to solve it?

Many thanks in advance.

Thomas

1. Re: Resource adapter based on Java Native Interface

rareddy Aug 30, 2017 5:19 PM (in response to tomesc)

You can configure resource adapter pool max size to be 1, so that there ever will be a single connection. Only one query is done then the second query gets the connection.
Actions
2. Re: Resource adapter based on Java Native Interface

tomesc Aug 31, 2017 2:49 AM (in response to rareddy)

Thanks a lot Ramesh. That helps for now.
However If anyone else has some information how to manage JNI within a connection pool, any help would be appreciated.
Actions
3. Re: Resource adapter based on Java Native Interface

rareddy Aug 31, 2017 5:37 AM (in response to tomesc)

I am not sure what you mean by 'JNI within a connection pool", this is your resource adapter, it is up to you how you are loading these JNI libraries. JNI libraries are allowed to load once per JVM. If there is a single instance of a resource adapter in your system, then that is fine, in that case, the issue really is the communication protocol does not allow the multiplexing of commands, so creating single connection will fix that. If you trying to instantiate multiple copies of the resource adapter, then there may be an issue JNI, as each instance might try to load the JNI libraries. If you are using Wildfly modules based loading [1] of JNI, I am thinking this issue will be resolved.

[1] JBoss Modules version 1
Actions
4. Re: Resource adapter based on Java Native Interface

tomesc Aug 31, 2017 8:53 AM (in response to rareddy)

I meant that your origin proposal solved the issue so far, but anyway I'd like to support multiple connections too. I am quite sure that the loading of the JNI library is not the problem, rather the JNI part which wraps the C-function to communicate with the EIS. This function links the JVM with the EIS and no matter how much instances of the JNI Wrapper will be created, all are using the same connection. I suspect I have to implement an own pooling mechanism in my JNI wrapper (or even in the C-Part) like the OracleOCIConnectionPool.
Actions
5. Re: Resource adapter based on Java Native Interface

rareddy Aug 31, 2017 9:17 AM (in response to tomesc)

> I suspect I have to implement an own pooling mechanism in my JNI wrapper (or even in the C-Part) like the OracleOCIConnectionPool.
A resource adapter (JCA) does come with the connection pool, so writing your own does not make sense. You just need to make sure you are creating a new connection if your JNI library allows on request to create a new connection. Since you are saying JNI only allows single connection then a multiplexing of requests is key, so you can create a framework that allows that then you can create your own connection framework on top it to manage it and also so that you fit into resource adapter semantics.

Since you are saying JNI only allows single connection then a multiplexing of requests on a single connection is key, so you can create a framework that allows that then you can create your own connection framework on top it to manage it and also so that you fit into resource adapter semantics.
Actions

Go to original post