We are trying to connect to IBM MQ from our Nifi instance(nifi-1.11.4) using the processor 'consumeJMS ' and the controller service 'JMSConnectionFactoryProvider'.
The JMSConnectionFactoryProvider is configured as shown below:
The consumeJMS processor is configured as shown below:
The Nifi instance is able to connect to the MQ channel and receive real-time messages when the MQ is configured without any security i.e without SSL. However, on configuring the MQ with security i.e with TLS V1.2 and also configuring the 'StandardSSLContextService' controller service , we get the error as shown below:
JMSWMQ0018: Failed to connect to queue manager 'XXXXXX' with connection mode 'Client' and host name 'XXXXXX.YY.com(1414)'.
CC=2;RC=2397;AMQ9204: Connection to host 'XXXXXX.YY.com(1414)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'ZZZZZZ.XXXXXX.04' to host ''. [3=ZZZZZZ.XXXXXX.04]],3=XXXXXX.YY.com(1414),5=RemoteConnection.analyseErrorSegment]
mqiException: CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'ZZZZZZ.XXXXXX.04' to host ''. [3=ZZZZZZ.XXXXXX.04]
2020-10-28 20:18:24,300 ERROR [Timer-Driven Process Thread-9] o.apache.nifi.jms.processors.ConsumeJMS ConsumeJMS[id=c26ce2ba-] Error while trying to process JMS message: org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing; nested exception is com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'XXXXXX' with connection mode 'Client' and host name 'XXXXXX.YY..com(1414)'.
Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2397' ('MQRC_JSSE_ERROR').
org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing; nested exception is com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'XXXXXX' with connection mode 'Client' and host name 'XXXXXX.YY..com(1414)'.
Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2397' ('MQRC_JSSE_ERROR').
CC=2;RC=2397;AMQ9204: Connection to host 'XXXXXX.YY..com(1414)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'ZZZZZZ.XXXXXX.04' to host ''. [3=ZZZZZZ.XXXXXX.04]],3=XXXXXX.YY..com(1414),5=RemoteConnection.analyseErrorSegment].
As discussed with our IBM Sever admin, they mentioned they have different ciphersuite setup on their side. They advised us to configure same Ciphersuite on NIFI instance in order to overcome this issue.
Server Side Error:
===================
Process(12232.3231) User(abc) Program(mqmgr123)
Host(VMServer) Installation(Installation1)
VRMF(0.0.0.01) QMgr(YYYYYY)
AMQ9639: Remote channel 'XXXXXX.YYYYYY.04' did not specify a CipherSpec.
EXPLANATION:
Remote channel 'XXXXXX.YYYYYY.04' did not specify a CipherSpec when the local
channel expected one to be specified.
The remote host is 'vmclient (00.001.00.05)'.
The channel did not start.
ACTION:
Change the remote channel 'XXXXXX.YYYYYY.04' on host 'vmclient
(00.001.00.05)' to specify a CipherSpec so that both ends of the channel have
matching CipherSpecs.
Related
I have a strange issue that took me several days to narrow down. Basically, I have a Jhipster project based on Spring boot Version 2.1.10.RELEASE, which contains 4 microservices. We are interested here in 2 of them: Gateway and Corehub.
In the gateway, I have an angular app that performs a POST to /services/corehub/api/someendpoint which used to be working and that is failing now with different error messages, but the one I have more regularly is
{
"type": "https://www.jhipster.tech/problem/problem-with-message",
"title": "Method Not Allowed",
"status": 405,
"detail": "Request method 'POST' not supported",
"path": "/services/ambientcorehub/api/trips",
"message": "error.http.405"
}
I ended up looking at the traces of the Registry that keeps track of the microservices for internal communication and I found out that when this error occurs, I cannot find the corehub in the traces anymore. So it looks like the corehub micro service is not registered.
An other GIT branch of this service does not have this problem, so I performed a diff between these two branches and I removed the changes until I could narrow down the problem.
So, in the corehub, I have a JMS listener based on this mq-jms-spring implementation. The maven dependency is as follows:
<dependency>
<groupId>com.ibm.mq</groupId>
<artifactId>mq-jms-spring-boot-starter</artifactId>
<version>2.2.7</version>
</dependency>
I commented out my JmsListener class and its associated JmsContext (to get access to a topic), and kept only the configuration properties defining access to the server, along with the port, channel, topic name, etc.
If I comment the above maven dependency, my service works again.
If I keep the maven dependency, with the configuration only, my corehub microservice is not registered in the Registry and becomes not accessible anymore from the gateway and thus the Angular UI.
What is important to note, is that I have currently some network issue which prevents me from accessing the JMS Server.
So I believe the exception that is raised by this IBM library because the JMS server is not reachable, breaks the registration of the microservice towards the spring boot registry.
Here are the traces that come over and over in the corehub console:
2020-07-22 08:21:45.316 WARN 7964 --- [nfoReplicator-0] o.s.boot.actuate.jms.JmsHealthIndicator : JMS health check failed
com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ0018: Failed to connect to queue manager '' with connection mode 'Client' and host name '172.31.14.1(9010)'.
at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:489)
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:448)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:8475)
at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:7815)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl._createConnection(JmsConnectionFactoryImpl.java:303)
at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:236)
at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6005)
at com.ibm.mq.jms.MQConnectionFactory.createConnection(MQConnectionFactory.java:6030)
at org.springframework.jms.connection.SingleConnectionFactory.doCreateConnection(SingleConnectionFactory.java:409)
at org.springframework.jms.connection.SingleConnectionFactory.initConnection(SingleConnectionFactory.java:349)
at org.springframework.jms.connection.SingleConnectionFactory.getConnection(SingleConnectionFactory.java:327)
at org.springframework.jms.connection.SingleConnectionFactory.createConnection(SingleConnectionFactory.java:242)
at org.springframework.boot.actuate.jms.JmsHealthIndicator.doHealthCheck(JmsHealthIndicator.java:52)
at org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:82)
at org.springframework.boot.actuate.health.CompositeHealthIndicator.health(CompositeHealthIndicator.java:95)
at org.springframework.cloud.netflix.eureka.EurekaHealthCheckHandler.getHealthStatus(EurekaHealthCheckHandler.java:110)
at org.springframework.cloud.netflix.eureka.EurekaHealthCheckHandler.getStatus(EurekaHealthCheckHandler.java:106)
at com.netflix.discovery.DiscoveryClient.refreshInstanceInfo(DiscoveryClient.java:1406)
at com.netflix.discovery.InstanceInfoReplicator.run(InstanceInfoReplicator.java:117)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2538' ('MQRC_HOST_NOT_AVAILABLE').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203)
... 24 common frames omitted
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2538;AMQ9204: Connection to host '172.31.14.1(9010)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2538;AMQ9204: Connection to host '/172.31.14.1:9010' rejected. [1=java.net.ConnectException[Connection timed out: connect],3=/172.31.14.1:9010,4=TCP,5=Socket.connect]],3=172.31.14.1(9010),5=RemoteTCPConnection.bindAndConnectSocket]
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.jmqiConnect(RemoteFAP.java:13558)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1426)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1385)
at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJmqiImpl.java:377)
at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:562)
at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:381)
... 23 common frames omitted
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2538;AMQ9204: Connection to host '/172.31.14.1:9010' rejected. [1=java.net.ConnectException[Connection timed out: connect],3=/172.31.14.1:9010,4=TCP,5=Socket.connect]
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.bindAndConnectSocket(RemoteTCPConnection.java:901)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:1381)
at com.ibm.mq.jmqi.remote.impl.RemoteConnection.connect(RemoteConnection.java:976)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getNewConnection(RemoteConnectionSpecification.java:553)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSessionFromNewConnection(RemoteConnectionSpecification.java:233)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSession(RemoteConnectionSpecification.java:141)
at com.ibm.mq.jmqi.remote.impl.RemoteConnectionPool.getSession(RemoteConnectionPool.java:127)
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.jmqiConnect(RemoteFAP.java:13302)
... 28 common frames omitted
Caused by: java.net.ConnectException: Connection timed out: connect
at java.base/java.net.PlainSocketImpl.connect0(Native Method)
at java.base/java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java:101)
at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:399)
at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:242)
at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:224)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403)
at java.base/java.net.Socket.connect(Socket.java:609)
at java.base/java.net.Socket.connect(Socket.java:558)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection$4.run(RemoteTCPConnection.java:1022)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection$4.run(RemoteTCPConnection.java:1014)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.connectSocket(RemoteTCPConnection.java:1014)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.bindAndConnectSocket(RemoteTCPConnection.java:805)
... 35 common frames omitted
Here are some version numbers:
jhipster-dependencies.version: 3.0.7
Spring boot version: 2.1.10.RELEASE
ibmmq-jms-spring version(s) that are affected by this issue: Version 2.2.7
Java version (including vendor and platform): AdoptOpenJDK\jdk-11.0.6.10-hotspot
A small code sample that demonstrates the issue.
Here is my configuration in application.yml:
spring:
jms:
# Used for JMS Message reception.
isPubSubDomain: false
application:
oag:
# This can be a queue or a topic (if subdomain is defined)
# In case of a topic, sub domain must be set to public.
queueName: "BRIDGE.XXX.TO.YYY.TST"
isTopic: false
ibm:
mq:
queueManager:
channel: XXX_GWT11.BT1
connName: 172.31.14.1(9010)
user: xxxx
password:
Would it be possible to catch this exception to avoid breaking regular Spring Boot registration mechanism?
I cannot afford having my cluster down because I cannot access the JMS server.
Beside this, I opened this message on IBM MQ side here and a person suggested me to stop the JMS health indicator. So I set the following property to no avail:
management:
endpoint:
jms:
# Prevent Unreachable JMS Server from unregistering corehub from the registry, leading to unreachable microservice from the Gateway
enabled: false
Corresponding documentation is here
Any help would be greatly appreciated.
Thank you
Christophe
If you do not want your application to be considered unhealthy when JMS is down, disabling the JMS health indicator is what I would recommend. It hasn't worked for you as you have used management.endpoint.jms.enabled. The correct property to use is management.health.jms.enabled:
management:
health:
jms:
enabled: false
Whenever I restart hazelcast server, without restarting client in spring boot. I'm getting following error :
03-01-2018 16:44:17.966 [http-nio-8080-exec-7] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet].log - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.hazelcast.client.HazelcastClientNotActiveException: Partition does not have owner. partitionId : 203] with root cause
java.io.IOException: Partition does not have owner. partitionId : 203
at com.hazelcast.client.spi.impl.ClientSmartInvocationServiceImpl.invokeOnPartitionOwner(ClientSmartInvocationServiceImpl.java:43)
at com.hazelcast.client.spi.impl.ClientInvocation.invokeOnSelection(ClientInvocation.java:142)
at com.hazelcast.client.spi.impl.ClientInvocation.invoke(ClientInvocation.java:122)
at com.hazelcast.client.spi.ClientProxy.invokeOnPartition(ClientProxy.java:152)
at com.hazelcast.client.spi.ClientProxy.invoke(ClientProxy.java:147)
at com.hazelcast.client.proxy.ClientMapProxy.getInternal(ClientMapProxy.java:245)
at com.hazelcast.client.proxy.ClientMapProxy.get(ClientMapProxy.java:240)
at com.hazelcast.spring.cache.HazelcastCache.lookup(HazelcastCache.java:139)
at com.hazelcast.spring.cache.HazelcastCache.get(HazelcastCache.java:57)
at org.springframework.cache.interceptor.AbstractCacheInvoker.doGet(AbstractCacheInvoker.java:71)
If I enabled hot-restart, the issue is solved. But is there a way to resume client application without restarting it and hot-restart is disabled ?
Hazelcast client tries to reconnect to the cluster if the connection drops. It uses ClientNetworkConfig.connectionAttemptLimit and ClientNetworkConfig.connectionAttemptPeriod elements to configure how frequently it will try. connectionAttemptLimit defines the number of attempts on a disconnection and connectionAttemptPeriod defines the period between two retries in ms. Please see the usage example below:
ClientConfig clientConfig = new ClientConfig();
clientConfig.getNetworkConfig().setConnectionAttemptLimit(5);
clientConfig.getNetworkConfig().setConnectionAttemptPeriod(5000);
Starting with Hazelcast 3.9, you can use reconnect-mode property to configure how the client will reconnect to the cluster after it disconnects. It has three options:
The option OFF disables the reconnection.
ON enables reconnection in a blocking manner where all the waiting invocations will be blocked until a cluster connection is established or failed.
The option ASYNC enables reconnection in a non-blocking manner where all the waiting invocations will receive a HazelcastClientOfflineException.
Its default value is ON. You can see a configuration example below:
ClientConfig clientConfig = new ClientConfig();
clientConfig.getConnectionStrategyConfig()
.setReconnectMode(ClientConnectionStrategyConfig.ReconnectMode.ON);
By using these configuration elements, you can resume your client without restarting it.
I recently upgraded to spring 4.1 from 3.1 and the jms:listener-container doesn't seem to wait for a timeout before retrying to setup listeners, as it used to in 3.1. I've tried recovery-interval="10000" and it's still trying around 3 times a second.
Here's the section of my spring config:
<jms:listener-container recovery-interval="10000" connection-factory="connectionFactory">
<jms:listener destination="${myQueueDestination}" ref="myListener" />
<!-- many others -->
</jms:listener-container>
My logs on 4.1 look like that (see times):
11/09 11:56:33 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed f or destination 'MYQUEUE.NAME' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2085'.
11/09 11:56:33 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'MYQUEUE.NAME' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2085'.
11/09 11:56:34 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed f (...)
And 3.1 looks like this (see 5 second delay):
11/09 12:14:32 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'MYQUEUE.NAME' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2085'.
11/09 12:14:37 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'MYQUEUE.NAME' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2085'.
11/09 12:14:43 WARN [org.springframework.jms.listener.DefaultMessageListenerContainer] Setup of JMS message listener invoker failed for destination 'MYQUEUE.NAME' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2085'.
When the queues are back up, it's all OK. Are these timeout settings available for configuration?
Regards
This definitely looks like a regression to me and something I just happened to find out yesterday as well. I have created this issue to track that problem.
My setup is Spring 3 JMS, MVC + Websphere MQ + Websphere 7
<!-- this is the Message Driven POJO (MDP) -->
<bean id="messageListener" class="com.SomeListener" />
<!-- and this is the message listener container -->
<bean id="jmsContainer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="connectionFactory" ref="xxxCF" />
<property name="destination" ref="someQueue" />
<property name="messageListener" ref="messageListener" />
</bean>
When I start up the server, the listener seems to start correctly since it receives the messages that are on the queue as I put them.
However, once I run any simple controller/action that doesn't even have anything to do with JMS it gives me the message below over and over...
DefaultMessag W org.springframework.jms.listener.DefaultMessageListenerContainer handleListenerSetupFailure Setup of JMS message listener invoker failed for destination 'queue:///ABCDEF.EFF.OUT?persistence=-1' - trying to recover. Cause: MQJMS2008: failed to open MQ queue ''.; nested exception is com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2042'.
DefaultMessag I org.springframework.jms.listener.DefaultMessageListenerContainer refreshConnectionUntilSuccessful Successfully refreshed JMS Connection
ConnectionEve W J2CA0206W: A connection error occurred. To help determine the problem, enable the Diagnose Connection Usage option on the Connection Factory or Data Source.
ConnectionEve A J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource JMS$XXXQCF$JMSManagedConnection#2. The exception is: javax.jms.JMSException: MQJMS2008: failed to open MQ queue ''.
ConnectionEve W J2CA0206W: A connection error occurred. To help determine the problem, enable the Diagnose Connection Usage option on the Connection Factory or Data Source.
ConnectionEve A J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource jms/XXXQCF. The exception is: javax.jms.JMSException: MQJMS2008: failed to open MQ queue ''.
The original listener seems to be still running correctly...but I think the controller is somehow triggering off another connection?
Does anyone know what I should check for or what might cause this issue?
thanks
The 2042 means "Object in use". Since there is no concept of exclusive use of queues for message producers, then one of your consumers is locking the queue.
This behavior is controlled by the queue definition's DEFSOPT attribute. This is at the queue manager itself and not in the managed object definitions or your factory options. From the command line while signed on as mqm (or the platform equivalent if the QMgr is on Windows, iSeries, z/OS, etc.) you would need to start runmqsc and issue the following commands to verify and then fix the problem. In my example, the QMgr is PLUTO and the example queue is SYSTEM.DEFAULT.LOCAL.QUEUE.
/home/mqm: runmqsc PLUTO
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager PLUTO.
dis q(system.default.local.queue) defsopt
1 : dis q(system.default.local.queue) defsopt
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) TYPE(QLOCAL)
DEFSOPT(EXCL)
alter ql(system.default.local.queue) defsopt(shared)
2 : alter ql(system.default.local.queue) defsopt(shared)
AMQ8008: WebSphere MQ queue changed.
dis q(system.default.local.queue) defsopt
3 : dis q(system.default.local.queue) defsopt
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) TYPE(QLOCAL)
DEFSOPT(SHARED)
If you display the queue and find that it is already set for DEFSOPT(SHARED) then something must be specifying exclusive use of the queue through the API. That typically means a C or base Java program since these non-JMS APIs have access to low-level WMQ functionality. Those can be a little trickier to diagnose and I usually use a trace or the SupportPac MA0W exit to display the API calls and options used. If this is the case, I'd want to know more about what is meant by "simple controller/action" as noted in the original post.
Finally, if the queue that you are accessing is a remote queue then it will resolve to a transmit queue. The channel will always set a transmit queue to GET(INHIBITED) and acquire an exclusive lock on it. This is consistent with WMQ functionality in that an application can only GET messages from a local queue.
I have a fresh install of Wesphere 6.1 Fixpack 23. I have an app deployed that requires an MQSeries JMS Queue. I set up an MQSeries provider-based request and reply queue and an MQSeries provider-based queue connection factory. When the deployed app tries to access the queue, I receive the following error.
Any assistance would be appreciated. Thanks!
[5/28/09 10:33:42:538 EDT] 00000033 ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: espaapp. Exception thrown : org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.UnsatisfiedLinkError: mqjbnd05 (Not found in java.library.path)
Caused by: java.lang.UnsatisfiedLinkError: mqjbnd05 (Not found in java.library.path)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:953)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:922)
at java.lang.System.loadLibrary(System.java:451)
at com.ibm.mq.MQSESSION.loadLib(MQSESSION.java:1028)
at com.ibm.mq.server.MQSESSION$1.run(MQSESSION.java:246)
at java.security.AccessController.doPrivileged(AccessController.java:192)
at com.ibm.mq.server.MQSESSION.(MQSESSION.java:243)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
at com.ibm.mq.MQSESSIONServer.getMQSESSION(MQSESSIONServer.java:68)
at com.ibm.mq.MQSESSION.getSession(MQSESSION.java:508)
at com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:213)
at com.ibm.mq.MQBindingsManagedConnectionFactoryJ11._createManagedConnection(MQBindingsManagedConnectionFactoryJ11.java:186)
at com.ibm.mq.MQBindingsManagedConnectionFactoryJ11.createManagedConnection(MQBindingsManagedConnectionFactoryJ11.java:225)
at com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:84)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:173)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:795)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:709)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:664)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:160)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:550)
at com.ibm.mq.MQSPIQueueManager.(MQSPIQueueManager.java:62)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2427)
at com.ibm.mq.jms.MQConnection.createQMXA(MQConnection.java:1806)
at com.ibm.mq.jms.MQQueueConnection.(MQQueueConnection.java:105)
at com.ibm.mq.jms.MQQueueConnection.(MQQueueConnection.java:66)
at com.ibm.mq.jms.MQXAQueueConnection.(MQXAQueueConnection.java:59)
at com.ibm.mq.jms.MQXAQueueConnectionFactory.createXAQueueConnection(MQXAQueueConnectionFactory.java:82)
at com.ibm.ejs.jms.JMSManagedQueueConnection.createConnection(JMSManagedQueueConnection.java:123)
at com.ibm.ejs.jms.JMSManagedConnection.(JMSManagedConnection.java:315)
at com.ibm.ejs.jms.JMSManagedQueueConnection.(JMSManagedQueueConnection.java:71)
... More
Does this help?
java.lang.UnsatisfiedLinkError occurs when connecting to a queue manager
Also, within the JMS -> Queue Connection Factories section, select your Queue Connection Factory and check if your "Transport Type" is set to 'BINDINGS' or 'CLIENT'
I swapped mine to CLIENT and that seemed to help a lot.
Such error often happens as a result of passing null to port, host or QManager to connection factory. Try to check all parameters during execution. Normally MQ does not require mqjbnd05 library.
Try to find this file
libmqjbnd05.so
Add that to the LIBPATH for your JVM and try again.
GO to WebSphere Admin console. Environment -> WebSphere variables. Look for MQ_INSTALL_ROOT and modify its value to your MQ installation directory [MQ Home].