hakish
hakish

Reputation: 4048

Accessing MQ with JMS

i am using MQ7 and trying to access a queue with JMS api's. Getting this error. Has anyone seen it before? How do i resolve this? TIA

Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSException: JMSFMQ6312: An exception occurred in the Java(tm) MQI. The Java(tm) MQI has thrown an exception describing the problem. See the linked exception for further information.

Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd' was not found. [3=mqjbnd]

Caused by: java.lang.UnsatisfiedLinkError: no mqjbnd in java.library.path

Upvotes: 10

Views: 32581

Answers (6)

Venu
Venu

Reputation: 1772

Add the below to your tomcat arguments:

-Djava.library.path="C:\Program Files (x86)\IBM\WebSphere MQ\java\lib64"

If the installation directory is different than the above, use the appropriate location.

Upvotes: 0

user5061020
user5061020

Reputation: 1

The issue is with Path variable on system properties. Try to run code by specifying MQInstallation Dir :\Lib64 path before MQInstallation Dir :\Lib

Upvotes: 0

Imam Baihaqi
Imam Baihaqi

Reputation: 175

Agree with Johnam, it happened because the ConnectionFactory set as server by default, it need to be set as client, you said that it works on same machine. Because I also met the same situation, it run when on same machine, in this case because your machine is as WMQ Server so do the program, but when you run on different machine then your program must set as client.

I fix it using set some parameter on ConnectionFactory:

<bean id="mqConnectionFactory" class="com.ibm.mq.jms.MQConnectionFactory">
....
<property name="transportType" value="1" />
<property name="clientReconnectTimeout" value="2" /> 
<property name="clientReconnectOptions" value="0" />
</bean>

Upvotes: 3

johnam
johnam

Reputation: 91

Probably a bit late but I had the same problem and found that this can be avoided if you use a different Connection Mode when connecting to a remote Queue. By default the MQConnectionFactory uses WMQ_CM_BINDINGS as it's connection mode. If you change it to WMQ_CM_CLIENT (or whichever connection mode you like that doesn't require native libraries) you should be fine.

@Test
public void testMQConnectionMode() throws JMSException {
    MQConnectionFactory cf = new MQConnectionFactory();
    assertThat(cf.getIntProperty(CommonConstants.WMQ_CONNECTION_MODE), is(equalTo(CommonConstants.WMQ_CM_BINDINGS)));
    cf.setIntProperty(CommonConstants.WMQ_CONNECTION_MODE, CommonConstants.WMQ_CM_CLIENT);
    assertThat(cf.getIntProperty(CommonConstants.WMQ_CONNECTION_MODE), is(equalTo(CommonConstants.WMQ_CM_CLIENT)));
}

Upvotes: 9

Tomboy
Tomboy

Reputation: 11

The VM parameter -Djava.library.path=/opt/mqm/java/lib64 works for me. My environment is 64bit Suse with MQ installed and my program is using 'Bindings' transport type

Upvotes: 1

T.Rob
T.Rob

Reputation: 31832

This is almost always caused by a combination of an incomplete client install and/or a CLASSPATH issue. Many people grab the jar files rather than performing the complete install and do not necessarily get all of them. In addition to insuring all required binaries are present, using the install media provides several additional capabilities such as diagnostics and trace. It also assures that maintenance can be applied. The WMQ client install media are available for free download as SupportPac MQC7. The CLASSPATH setting should be as described in the WebSphere MQ Using Java manual.

If the client install is performed from the IBM media and the environment is set up as per the docs, this fixes nearly all cases such as you have reported here. There are a few Install Verification Test apps (some of those diagnostics installed with the full media that I mentioned) which are described here and which can help determine if a problem is with the installation or with the code.

Upvotes: 3

Related Questions