I did a lot of reseach, and I'm stuck at a later phase now in our implementation as client ...
In short the requirements are:
SSL
Client app does Load-balancing. We need separate CCDT files in one application so we can handle all connections ourselves.
Unmanaged mode is used for SSL
XMS is used for asynchronous automatic consumption of incoming messages instead of polling the queue
IBM MQ Client V8.0.0.5 is used
We connect to 4 QMs. Everything is the same in the 4 connections except the port. QM name is '*'.
To configure separate CCDT files we can configure XMSC.WMQ_CCDTURL, but in unmanaged mode this is ingored. If I only change the connection mode to CLIENT mode (CT_WMQ) then it looks in the right configured directory. But when using unmanaged mode, this property is ignored.
This question is also asked here: https://www.ibm.com/developerworks/community/forums/html/topic?id=0268e8f5-8562-4b28-a621-32e20dee0c53
I try same settings, once with client mode and once with unmanaged mode. Event viewer gives different output related to CCDT. In unmanaged mode it looks for the default location.
Client mode event viewer event: http://pasted.co/27db600f (CCDT does not exist but it looks in the right directory which is good)
Unmanaged mode event viewer event: http://pasted.co/d5979a2c
Please help in setting separate CCDTURLs for these 4 separate connections. Don't ask me to use one CCDT with all the defined connection in it, that's not what we want because we want to do the load-balancing ourselves.
Related
I create a queue manager like QMTEST in IBM WebSphere MQ Explorer. I want to connect to a remote queue manager (remote ip address). I followed these steps:
add remote Queue manager
Queue manager name: QMTEST [Next]
Host Name or ip Address: X.X.X.X(remote ip) [Finish]
But I couldn't connect. I got this error message 'Could not establish connection to the queue manager-reason 2538.(AMQ4059)'. What can I do?
The four digit number in your error message is an MQRC (MQ Reason Code). This number gives you more information about what went wrong. You can look it up in Knowledge Center.
MQRC_HOST_NOT_AVAILABLE (2538)
There is a list of possible things that could cause this error. My guess is it is likely to be the first one, you have not started a listener on the queue manager, since you do not mention doing that in your question details.
You should also read the following link which is some basic details on how to connect to a remote queue manager. You appear to have the MQ Explorer side sorted, but perhaps not the queue manager side.
Setting up the server using the command line
Please ensure the listener is running on the remote queue manager side. The default MQ listener port is 1414. If the listener is running then check the queue manager error logs for any connection errors from the MQ explorer.
Are you sure the qmgr and its listener are running and that you have a SYSTEM.ADMIN.SVRCONN channel? That is the server-connection channel used for remote administration of a queue manager. This technote may be helpful.
Is this on a modern Windows or Linux server? If so, did you open the port (i.e. 1414) in the firewall?
Sometimes when we create a Queue manager remote administration objects are not created that's why we get such errors because it is unable to find these objects. To create them right click on the queue Manager, Select Remote Administration objects and create them and start the listener.
I experienced this same error and the queue was configured correctly.
I was using Eclipse and switched to the MQ Explorer setup available from IBM web page.
After that, I was totally able to see the queues and everything I was supposed to see.
We are using WebSphere MQ client adapters on an AIX box to send messages via MQ. We send them to the outbound remote queue on the same box and find it quite slow to get to their destination - a 27mb file takes 3 minutes to run the MQQueue.put command.
Bizarrely we can change the send parameters to send to an outbound remote queue on an entirely different box and it will send the file in 2 seconds. Similarly coming back to this box from elsewhere will be quick. And sending from another box to the outbound remove queue on that same box is also slow.
So in summary the problem appears to be when sending to the outbound remote queue on the same box - we have tried specifying the destination by dns name, ip address, 127.0.0.1 etc, but no luck.
Would be grateful for any advice.
Try see if tcp_nodelayack makes a difference on the box. If you are at a new enough MQ level (which one are you at?) then you can just set MQ_SET_NODELAYACK to affect just MQ or alternatively (or for a quick test) just set it system wide on AIX with the 'no' command listed in the first link below.
See http://www-01.ibm.com/support/docview.wss?uid=swg21320862
FYI apar which adds the MQ specific env var option
http://www-01.ibm.com/support/docview.wss?uid=swg1IZ43635
As an aside I'd also recommend trying MQ v8 client to stop MQ playing with the buffer sizes and let the o/s default them, but from the sounds of your problem I would not be surprised if the above helps.
After using MQ Explorer 7.5 on Ubuntu 12 to add JMS Connection factories and a JMS Destination it decided to stop displaying my two queues and subsidiary info as well as the new JMS information. I tried a few things to get it to work again: stopping the queue manager/restarting, rebooting etc. even reinstalling MQ Explorer without any luck.
I can do a status on the "empty" queues folder and it then shows me my two queues; each has "queue monitoring" set as off. Is this relevant? Can I set it on ?
Am I stuck with MQ Explorer to display and manage the JMS objects (there doesn't seem to be any documentation about how to use the command line for JMS objects) ?
more detail:
so I created objects using the following:
DEFINE QLOCAL (QUEUE_FROM)
DEFINE QLOCAL (QUEUE_TO)
SET AUTHREC PROFILE(QUEUE_FROM) OBJTYPE(QUEUE) PRINCIPAL('bsmith') AUTHADD(PUT,GET)
SET AUTHREC PROFILE(QUEUE_TO) OBJTYPE(QUEUE) PRINCIPAL('bsmith') AUTHADD(PUT,GET)
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('bsmith') AUTHADD(CONNECT)
DEFINE CHANNEL (CHANNEL1) CHLTYPE (SVRCONN) TRPTYPE (TCP)
SET CHLAUTH(CHANNEL1) TYPE(ADDRESSMAP) ADDRESS('127.0.0.1') MCAUSER('bsmith')
DEFINE LISTENER (LISTENER1) TRPTYPE (TCP) CONTROL (QMGR) PORT (1415)
START LISTENER (LISTENER1)
So these were all visible then in MQ Explorer using a user that was part of group mqm.
I then added, using MQ Explorer, a file based JMS context, two JMS Connection Factories, and a JMS Destination. After adding the JMS Destination the MQ Explorer stopped displaying everything except the Queue Manager and the JMS context in the MQ Explorer UI.
if I try to start the LISTENER again using the command START LISTENER (LISTENER1) it will tell me that it is already started. When I add a new queue to the queue manager using a command it also is not visible on the UI. A refresh doesn't change this.
/etc/environment is set to:
export JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45
export MQSERVER="SWI_CHANNEL/TCP/COM22189(1415)"
export MQ_JAVA_LIB_PATH=/opt/mqm/java/lib64
export MQ_JAVA_INSTALL_PATH=/opt/mqm/java
export MQ_JAVA_DATA_PATH=/var/mqm
export LD_LIBRARY_PATH=/opt/mqm/java/lib64
CLASSPATH=.:/opt/mqm/java/lib/com.ibm.mq.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt/mqm/samp/wmqjava/samples:/opt/mqm/samp/jms/samples:${JAVA_HOME}:${MQ_JAVA_LIB_PATH}:${CLASSPATH}
PATH=".:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:${JAVA_HOME}/bin:${JAVA_HOME}:/usr/lib/jvm/jdk1.6.0_45/jre/bin:${MQ_JAVA_LIB_PATH}"
trying the JMS Admin tool suggested gives :
/opt/mqm/java/bin$ ./JMSAdmin -v
Licensed Materials - Property of IBM 5724-H72, 5655-R36, 5724-L26,
5655-L82 (c) Copyright IBM Corp. 2008, 2011 All Rights Reserved. US
Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp. Starting
WebSphere MQ classes for Java(tm) Message Service Administration
Initializing JNDI Context... INITIAL_CONTEXT_FACTORY:
com.sun.jndi.fscontext.RefFSContextFactory PROVIDER_URL:
file:/C:/JNDI-Directory JNDI initialization failed, please check your
JNDI settings and service. The name '"/C:/JNDI-Directory"' cannot be
resolved
Error: javax.naming.NameNotFoundException; remaining name
'"/C:/JNDI-Directory"
The error Error: javax.naming.NameNotFoundException; remaining name '"/C:/JNDI-Directory" can be resolved by creating a folder named JNDI-DIRECTORY in C drive. This is the place where .bindings file will get generated.
My problem is that I have two servers, one running MQ Server and one running service which will get MQ messages from the former. However easily it sounds, I cannot make the latter to connect to the queue manager on the first server. I tried the following actions:
Ping the first server from the second one: it works just fine
Telnet the first server from the second one, using specific port used to connect MQ Manager on the first server (1416): it also works find
Now it comes the weird part: I created one Queue Manager on the second server (there is also a MQ Server running on that machine), with the same name with the MQ Manager on the first server that I want to connect, then I can only connect to this queue, although in the ChannelInfo I specify exactly the first server's IP address, not the second's.
After deleting the MQ Manager on the second server, it just gives me error 2058: MQRC_Q_MGR_NAME_ERROR. I checked the MQ Mananer name on the first server, it was correct.
It is possible to connect from other servers to the first server's MQ Manager.
More information that I doubt it is the source of my problem: the first server running Windows 32 bits and the second one is running Windows 64 bits. Moreover the second one is fresh installed, so I think it might have problem with some sorts of permissions. However searching around didn't help me so far.
I really appreciate if someone here could shed some lights on my problem. It made my project overdue deadline for a week already.
Thanks in advance!
No the error is not due to 32/64 bit Windows platform.
On both 32 bit as well as 64 bit Windows platforms queue manager runs as a 32 bit process.
So that's not the issue.
Obvious things to verify on the first server:
Have you defined a listener for the queue manager to listen on port 1416? If yes, is it running?
Have you defined a server connection (SVRCONN) channel on the queue manager?
How does your service(running on second server) attempt to connect to the queue manager? Is it bindings or client mode? In bindings mode, an application can connect only to the queue managers running on the same machine. In client mode, applications can connect to queue manager running on the same machine or a different machine. Your service must use a client mode connection to connect to remote machine.
To connect to remote queue manager, the application must specify the host name, port and channel name.
I am trying to connect to Websphere MQ 7.1 with Hermes JMS but I am not able to. I have followed their giude, loaded all the jars without problems, set the plugin, set all the variables (hostname, port, transportType, queuemanager), checked the box at the bottom that says user and typed the username and password and after confirming I tried to discover however I get the following message back:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at
com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233)
at
com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) at
com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at
com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95)
at
com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at
com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
at
com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770)
at
com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719)
at
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) at
hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107)
at
hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280)
at
hermes.impl.HermesAdminAdapter.discoverDestinationConfigs(HermesAdminAdapter.java:82)
at
hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126)
at
hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175) at
hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170) at
java.lang.Thread.run(Thread.java:662)
After a few hours of trial and error and research on the net, it seems that the issue is that it cannot connect due to bad authorization however I am able to connect using Java code (Using same lib MQQueueConnectionFactory) and I am also able to connect using QueueZee with the exact same libraries, get a list of all queues and browse them so I know user authorization issues should not be the problem.
I am running Hermes JMS 1.14 and I tried using both Java 1.6.0_33 and 1.7.0_5. Websphere MQ is running on version 7.1.0.0 and the libraries were gotten from this installation on a remote server.
I tried setting the channel variable to SYSTEM.DEF.SVRCONN which is what I used in QueueZee to get it to work but still the same issue.
Has anybody seen this issue before and hopefully can shed some light in the situation?
At V7.1 the new CHLAUTH rules shut off access to all SYSTEM.* channels except SYSTEM.ADMIN.SVRCONN by default and do not allow any administrative access on any SVRCONN channel by default. In order to diagnose this it would be necessary to know what channel was used, the CHLAUTH rules that are set, the channel definition (in particular, the MCAUSER value) and whether the ID used is in the mqm group.
You didn't mention whether the QueueZee setup was also to a V7.1 QMgr or this one in particular. Taking a wild guess, I'd say that CHLAUTH rules are enabled and that the SYSTEM.DEF.SVRCONN channel is disabled at this point. Recommended steps are to define a new channel whose name doesn't start with SYSTEM. and make sure the ID used is not in the mqm group but is authorized as a non-admin ID.
Alternatively, an ID in the mqm group can be used but you'd have to define a CHLAUTH rule to allow it to work. For example, the default CHLAUTH rule uses CHANNEL(*) BLOCKUSER(*MQADMIN) and you could change that to CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). The new rule would be more specific than the old rule and thus take precedence on your channel. It tells the QMgr to block the user ID 'nobody' but omits any mention of *MQADMIN. Since 'nobody' doesn't have access anyway but since *MQADMIN is not mentioned (and thus not blocked by thei rule) the effect of the rule is to allow admins on this channel.
As a quick, dirty and temporary measure, you can also ALTER QMGR CHLAUTH(DISABLED) to get the same behavior as in v7.0 and earlier QMgrs. Be aware though that this allows anonymous remote admin and remote code execution using the mqm user ID. That's why the default settings were changed. Now you must explicitly provision remote admin access if you need it.
For more on this topic, I recommend the Securing Your QMgr presentation from the IMPACT conference.
Note that the password the app sends in is not checked by the QMgr. The field exists so that channel exits can validate the password against AD, LDAP, etc. Without such an exit, the password is ignored. The user ID passed in by the client is either accepted at face value or modified by the channel's MCAUSER or by CHLAUTH rules.
Finally, when having authorization problems the easiest way to diagnose is to ALTER QMGR AUTHOREV(ENABLED) and then use SupportPac MS0P to decode the PCF messages in WMQ Explorer. The auths errors end up in the QMgr Event queue. Each message tells you the object that failed auths, the API call made against that object, the options of the call and the ID that made the call. Often we find the ID making the call isn't the one we wanted or that the program is using options it isn't authorized for so this can be extremely helpful.
Not really an answer, just a little research on the problem.
I have faced the same problem about hour ago. I am passing the username like domain\sortoflongusername and what i see in systemlog on WSMQ server is that my username is being truncated to 12 symbols.
I'm not really familiar with hermesJMS and soapui at all (just wanted to offer it to our testers to check it out as testing platform), so maybe anyone here does know about roots of this problem.