My configuration
MDB using activation specs on WAS 7
Default MQ Resource adapter config
Time to time, the connection is lost between the WAS and MQ and the MDB shuts down. Is there an easy way to send emails when it happens other than by activating the tracing on the resource adapter and defining a smtp log appender?
As far as I know there is no way to send an eMail when the connection between WebSphere and MQ is lost.
But you can configure WebSphere to try to reestablish the lost connection. You can configure the number of reconnect retries as well as the time interval between two retries.
With the default configuration WebSphere stops retries to reestablish a lost connection after a relative short time. I asume between 20 to 30 minutes.
If you use a listener port to connect your MDB to MQ you have to set properties of the listener port service. Search for MAX.RECOVERY.RETRIES and RECOVERY.RETRY.INTERVAL in online WebSphere documentation.
If you use an activation specification you have to configure the properties of the built-in MQ Resource adapter. This is a tricky thing, as this resource adapter is not displayed in WebSphere amdin console per default. Open WebSphere Admin console > Resource > Resource adapter and open the preferences. There you have to click the checkbox "show built-in resource adapter" and then "Apply". You can find the recovery settings for lost connections in the MQ Resource adapter's custom properties. Be sure you select the adapter with the same scope as your activation specification.
Hope that hepls.
Related
We currently have issues after connecting a new MQ Server (IBM MQ v9) to our service.
The current expectation is that we have two issues:
The connection establishment at MQ-Server takes too much time
We assume that on every message send a new physical connection is established instead of using the payara pool
Especially to prove No. 2 - is there any possibility to find out or log every Connection establishment that is done by the Resource Adapter?
You can use the Application activity trace of IBM MQ.
There is also a very nice presentation available to find out more about how to use the Activity Trace.
I'm trying to send a message to a IBM MQ queue from my spring boot service. I could send/receive the message from the IBM MQ installed on my laptop.
However when I replaced the configuration to connect to the IBM MQ Cloud, this is not working
Configuration is as follows:
getting the following error
Note:
I could telnet into the host & port
I tried with the following for Username & Password
With APIKey & App Name
My IBM Username & Password
It seems to be a known issue:
The connection may be broken for a number of different reasons. The 2009 return code indicates that something prevented a successful connection to the Queue Manager. The most common causes for this are the following are:
A firewall that is terminating the connection
An IOException that causes the socket to be closed
An explicit action to cause the socket to be closed by one end
The queue manager is offline
The maximum number of channels allowed by the queue manager are open
A configuration problem in the Queue Connection Factory (QCF)
Can you please try suggestions from here
Usually, the most common reason for Error Code 2009: MQRC_CONECTION_BROKEN is that your JMS client opens up multiple connections to the queue and they remain unclosed even though they're not being used. You then eventually run out of channels. You can increase the channel size to more than double of what is required.
Check your FFST log file generated by IBM MQ classes for JMS. It gives you detailed info on connections/errors:
First Failure Support Technology ( FFST ) files
I am configuring WAS to connect to MQ via CCDT, and should be using a Queue Manager Name with wild cards, i.e *QMan.
It is accepted in the Queue Connection Factory Screen and in the Activation Spec Screen, but it is not accepted in the Queue Configuration Screen. As shown on the below image, I am forced to leave the Queue Manager field blank. And my application is not received MQ messages. I am suspecting this might be the reason.
Any ideas why I cannot configure the Queue Manager in Queue screen? And what is the common problem if message listener is not receiving, even if the MQPUT is working.
I had double checked my CCDT configuration in Activation Spec, and have check the jndi names, everything is configured correctly.
Also note that it is working if I connected directly to the MQ via host/port etc. But I have to use CCDT to utilize our MQ cluster.
The Queue Manager (or Queue Sharing Group) name on the JMS Queue panel defines where the queue is located and not how you connect to it. It is the Queue Manager name in the JMS connection factory or activation specification that defines which queue manager your application connections to.
So it is correct that you can't enter a * in this box.
If the connection is not working when using a CCDT then it is likely to be another problem that this Queue Manager name box. Note: you can't use an XA connection with CCDTs due to the fact that a CCDT won't guarantee you will connect back to the same queue manager in the event of XA recovery.
I'm a beginner on WebSphere MQ, I was working on MQ 6 and it was working fine, but now I've installed MQ 7.1 and when I try to create a new Queue Manager I can do it But it can't connect and it gives me the following error :
Do you have any idea about that? Thank you :)
You can look up any WebSphere MQ error code if either the WebSphere MQ Client or Server are installed using the mqrc command. In this case:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
The 2059 usually indicates that the listener is not running or the queue manager is down. There's a different error code if the listener is running and the QMgr name is wrong and another one if the connection is made to the right QMgr but the channel name is wrong. Sometimes you can get a 2059 if the channel was closed at the server side by an exit but since you didn't mention any exits, I'm assuming in this case that its listener problem.
Hopefully by now you are defining a listener object rather than using inetd or the runmqlsr command. Defining an object and setting it to start and stop under QMgr control is the most reliable way to configure it.
Once you get past the 2059, you should be aware that as of WMQ V7.1, the queue managers are secure by default and won't accept any remote client connections unless you explicitly authorize them. This is the opposite of the behavior of V6 where on a newly defined queue manager running a listener, anyone with a TCP route to it could administer it and remotely execute OS code as the mqm user. So I expect that the next problem you run into will be 2035 errors.
I've been told this means more work for the WMQ administrator. The only case in which that's true is if the V6 or earlier queue manager had been configured without security. If the tasks to secure a V7.0 QMgr are compared to the tasks to provision access on a v7.1 and higher QMgr are compared, provisioning access turnds out to be easier. However if you liked the V7.0 behavior, you can always alter the QMgr to disable CHLAUTH rules. Needless to say, leaving security enabled is highly encouraged.
To debug security errors, alter the QMgr to enable authorization events using the runmqsc command ALTER QMGR AUTHOREV(ENABLED). Next, download and install SupportPac MS0P into WebSphere MQ Explorer. Then when you do get a security error, use WebSphere MQ Explorer to look at the queue. Right-click on the queue and select the option to parse the event messages. This will tell you in excruciating detail all the information you need to debug the authorization error.
Finally, if you wish to read up on the new security features, go to t-rob.net/links and look at the conference presentations there. There are also some articles indexed if you scroll down.
In the screen-shot, I see hostname "127.0.0.1" and port # 1414. If it is a local queue manager then connect directly to it.
Also, each queue manager MUST use a unique port number. If you had it working with WMQ v6 queue manager, is this the same queue manager? If not, then make sure each queue manager uses a different port number (i.e. 1415, 1416, etc...)
I got same problem. but i resolved this by :
1. created a listener manually (define lstr(lstr1) port(xxxx) control(qmgr)
2. setmqaut mcauser('mqm').
When I go to my WebSphere MQ explorer, and connect to a remote queue manager and go to --> Advanced --> Listeners, I do not see any listeners defined. But I am able to create a remote JMS client, connect to this queue manager by using a channel connection and publish a message to a topic.
So what is the purpose of listeners? In my case, things are working fine without listeners.
WebSphere MQ listeners are what accepts remote connections and start inbound channels. Modern queue managers will almost always have listeners defined but it is also possible to specify a default port for the QMgr to listen on without actually defining a listener. This is unusual, though. For older versions of MQ it was common to use inetd to start channels. This method doesn't use a listener.
So rest assured that something on your QMgr is listening for connections. Since you are not seeing it there are three likely possibilities:
The listener name starts with SYSTEM. and your Explorer view is set to filter SYSTEM objects.
The default port has been specified in the qm.ini file
You have a really old QMgr using inetd
By the way, go get a new version of WMQ Explorer. Since you have an Advanced --> Listeners you must have an old version. Download from SupportPac MS0T.