Saturday 20 June 2015

JMSFMQ6312 - Fun and more games with WebSphere Application Server, JMS and WebSphere MQ

A long time ago, in an office far far away, I hit a problem with WebSphere MQ and Java Messaging Service and WebSphere Application Server.

Specifically, the issue related to the interaction between WAS and WebSphere MQ using the Messaging Providers built into WAS.

I wrote about it here: -


This pertained to WAS on Unix.

This time around, I'm hitting the same issue, with WAS on Windows, as part of an IBM Integration Designer 8.5.6 deployment.

This is what I saw in the WAS server's SystemOut.log: -

[20/06/15 05:51:15:435 BST] 00000216 SibMessage    W   [:] CWSJY0003W: MQJCA4023: Startup reconnection failed for ActivationSpec 'javax.jms.Queue:CustomerService/MQJmsImport1_MQ_RECEIVE_D@IB9QMGR <-1336863013>'. Exception details: '
                       Message : 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.
                         Class : class com.ibm.msg.client.jms.DetailedJMSException


...
 ----------------------------------------------------------------------- 
 | Failed to load the WebSphere MQ native JNI library: 'mqjbnd'. 
 | 
 | The JVM attempted to load the platform native library 'mqjbnd', 
 | which was mapped to the filename: 'mqjbnd.dll'. 
 | 
 | When attempting to load the library, the JVM reported the error 
 | message: 
 | 'mqjbnd (c:\Program Files\IBM\WebSphere MQ\java\lib\mqjbnd.dll is not a valid Win32 application. )' 
 | 
 | The JVM's bit-size is: '64' 
 | 
 | The library path which was used to locate this library was: 
 | '*** Configured java.library.path **********************************
|  "C:\IBM\IID\PS\v8.5/lib/native/win/x86_64/"
|  "C:\IBM\IID\PS\v8.5\java_1.7_64\jre\bin\compressedrefs"
|  "C:\IBM\IID\PS\v8.5\java_1.7_64\jre\bin"
|  "C:\Windows\system32"
|  "C:\Windows"
|  "C:\IBM\IID\PS\v8.5\lib\native\win\x86_64"
|  "C:\IBM\IID\PS\v8.5\bin"
|  "C:\IBM\IID\PS\v8.5\java_1.7_64\bin"
|  "C:\IBM\IID\PS\v8.5\java_1.7_64\jre\bin"
|  "c:\Program Files\IBM\WebSphere MQ\java\lib"
|  "c:\Program Files\IBM\WebSphere MQ\java\lib64"
|  "C:\Windows\system32"
|  "C:\Windows"
|  "C:\Windows\system32\wbem"
|  "C:\Windows\system32\windowspowershell\v1.0\"
|  "c:\program files\ibm\gsk8\lib64"
|  "c:\program files (x86)\ibm\gsk8\lib"
|  "C:\IBM\IID\PS\v8.5\db2\BIN"
|  "C:\IBM\IID\PS\v8.5\db2\FUNCTION"
|  "C:\IBM\IID\PS\v8.5\db2\SAMPLES\REPL"
|  "c:\Program Files\IBM\WebSphere MQ\bin64"
|  "c:\Program Files\IBM\WebSphere MQ\bin"
|  "c:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin"
|  "."
|  ""
| ********************************************************************' 
 | 
 | Check that the bit size of the JVM matches the bit size of the first 
 | native library file located within this java.library.path directory 
 | list. 
 | 
 | The native library 'mqjbnd' is used by the WebSphere MQ classes for 
 | Java and WebSphere MQ classes for JMS when creating a connection to 
 | the queue manager using a 'bindings' mode connection. A bindings 
 | mode connection is a connection which uses the system's memory to 
 | communicate with the queue manager, as opposed to a 'client' mode 
 | connection which uses a TCP/IP socket. 
 | 
 | In order to communicate with a queue manager using a bindings mode 
 | connection, the queue manager must be located on the same system as 
 | the WebSphere MQ classes for Java/JMS. If this is not the case in 
 | your environment, consider reconfiguring the application to utilise 
 | client mode connections. 
 -----------------------------------------------------------------------

...
     Caused by [2] --> Message : java.lang.UnsatisfiedLinkError: mqjbnd (c:\Program Files\IBM\WebSphere MQ\java\lib\mqjbnd.dll is not a valid Win32 application. )
...
[20/06/15 05:51:15:439 BST] 00000216 ActivationSpe E   J2CA0138E: The Message Endpoint activation failed for ActivationSpec CustomerService/MQJmsImport1_AS (com.ibm.mq.connector.inbound.ActivationSpecImpl) and MDB application CustomerServiceApp#CustomerServiceMQJmsImport1#CustomerService due to the following exception: com.ibm.mq.connector.DetailedResourceAdapterInternalException: MQJCA1011: Failed to allocate a JMS connection. An internal error caused an attempt to allocate a connection to fail. See the linked exception for details of the failure.


The solution ?

Yes, I needed to set the Native Library Path for the same WebSphere MQ Messaging Providers.

Given that I'm running a 64-bit JVM on a 64-bit OS with a 64-bit MQ, I set the NLP to: -

C:\Program Files\IBM\WebSphere MQ\java\lib64

using some Jython: -

AdminTask.manageWMQ('"WebSphere MQ Resource Adapter(cells/PSCell1/nodes/Node1|resources.xml#J2CResourceAdapter_1434712637566)"', '[-nativePath "C:/Program Files/IBM/WebSphere MQ/java/lib64 " ]') 

Of course, I did also need to remember that it's necessary to restart WAS not once but TWICE, in order to avoid: -

[20/06/15 06:08:31:455 BST] 00000092 ActivationSpe E   J2CA0164E: The lookup of the Destination with JNDI Name CustomerService/MQJmsImport1_MQ_RECEIVE_D failed. The Destination is required by the Activation Specification. The lookup failed due to exception com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object. [Root exception is javax.naming.NamingException: WMSG2003E: It was not possible to lookup the specified WebSphere MQ administered object because the application server needs a restart to register an update to the WebSphere MQ installation.]
Caused by: javax.naming.NamingException: WMSG2003E: It was not possible to lookup the specified WebSphere MQ administered object because the application server needs a restart to register an update to the WebSphere MQ installation.
,,,

Once I restarted TWICE, all was back in order, which is nice :-)





No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...