The inspiration for this post comes from a post by ThirdInstance I ran across on the WebSphere Application Server forum on developerWorks.
If you use WebSphere Application Server (WAS) and WebSphere MQ (WMQ) together and you're seeing UnsatisfiedLinkError exceptions then keep reading!
The cause of an java.lang.UnsatisfiedLinkError, with respect to WMQ interactions, stems from a condition in which a native-language method definition (that is, a method declared with the native modifier in the Java code) is encountered but the JVM cannot locate the native library from which the native method is to be invoked from. In simpler terms: the Java code is trying to utilize some native libraries and the library files (e.g. library.so, library.a, library.dll, etc.) are not found in the MQ_INSTALL_ROOT WebSphere variable or in a native library definition (I.e. shared library, java.library.path argument, or WMQ JMS Provider definition).
To fix this:
- If you've already put a value in the MQ_INSTALL_ROOT (WAS versions prior to v7.0) or WMQ JMS Provider settings (WAS v7.x and on), confirm that the path actually does point to the libraries needed by the JVM.
- If you have not configured the MQ_INSTALL_ROOT or WMQ JMS Provider settings (again, WAS v7.x and up), refer to the following bullets:
- Setting MQ_INSTALL_ROOT
- To set this value examine the appropriate WebSphere variable scope (e.g. Cell, Node, Cluster, Server – Note: the default setting should exist at the Node scope) and provide the correct path to the WMQ native libraries.
- Setting the WMQ Resource Adapter settings: Open the JMS Provider definition for the WebSphere MQ Messaging Provider and enter the correct path to the MQ native libraries (or resource adapter JAR location). A screen capture of the JMS Providers panel is provided below for reference.
JMS Providers panel (click image to enlarge)
- If your WMQ resources are not local then you don't need to use the native libraries to connect and you should reconfigure your Connection Factory's transport type from BINDINGS to CLIENT. BINDINGS allows for extremely fast same-server shared memory interaction between the WAS JVM and the WMQ server code. CLIENT, however, provides a pure Java method of connecting and utilizing WMQ resources via network sockets.
One last thing to note. UnsatisfiedLinkErrors can also crop up when the problem is not related to missing native library files. It can also occur if an application that requires native libraries is restarted and the application class loader attempts to reload the native libraries again. Since the libraries are already loaded with the application the first time it was started, the exception is thrown. Configuring you native library requirements in a WebSphere Shared Library can help you avoid this problem during application restarts.