|Applies To||Packaged Custom Application RSA ACE/Agent for Java|
|Issue||ACEAgent5Wrapper.dll already loaded in another classloader|
AceAgent5Wrapper: library load error:
class = class java.lang.UnsatisfiedLinkError
message = Native Library C:\code\Java\ACEAGentJNI-PS\Example\lib\nt\ACEAgent5Wrapper.dll already loaded in another classloader
com.rsa.ps.ACEAgent.ACEException: Configuration problem: failed to link ACEInitialize function.
|Cause||This problem relates to the underlying design of the WebApp running on the Java Application server, and is a common issue for people writing Java AppServer code connecting to JNI code.|
If we are talking about a pure Java class that has been destroyed, it will live on in memory until a garbage collection has occurred. When we are looking at JNI code then the problem is magnified. Even if you try to force a garbage collection ( e.g. System.gc() ), you cannot dictate full control of the garbage collection process.
|Resolution||RSA Security can offer Professional Services assistance in helping in the design of web applications accordingly, but there are also a number of high-quality discussions on the Internet that discuss this problem and some possible solutions. As a recommendation, use an Internet search engine to search for "unload" "JNI" "DLL".|
One promising approach is to put your back-end code talking to the JNI wrapper into a listener class.
This model is also the standard mechanism advised in Java documentation for multi-threading, where the most effective model is often referred to by the "Producer Cubby-Hole Consumer" model. This basically means that your front-end JSP code is the producer of requests (and you could get many at the same time), which then pass their requests though to the single Listener task at the back-end which has loaded the JNI DLL just the once.
The JNI DLL and the wrapper around it will work fine within this multi-threading environment by using handles to manage the simultaneous access.
|Legacy Article ID||a25254|