Can anyone possibly give an example of how to setup within ITRS how to monitor an MQ queue using the mq-queue plugin? I have two screenshots below of what it is looking for. I am not sure how this would help us to determine how many messages are stuck within the queue?
The settings under the Advanced tab tell the plugin how to connect to the IBM MQ queue manager. How you configure these settings would depend on how the SVRCONN channel is configured on the queue manager. If you have any specific questions about these settings please update the question with more details.
On your queue manager you need to have a SVRCONN channel defined that will allow you to connect with a user that has been provided the following permissions:
+connect +dsp on the qmgr.
+put +inq on the SYSTEM.ADMIN.COMMAND.QUEUE
+get +dsp on the SYSTEM.DEFAULT.MODEL.QUEUE
+dsp +inq on any local queue you want to monitor
The settings on the Basic tab tell the plugin the name of the queue manager, the names of the queues on that queue manager, and the information you want to monitor (Columns). You can only monitor local queues. You would specify the queue names you want to monitor either one on each line using "matches" or if they all have a similar prefix you can use "startsWith" to match multiple queues.
To monitor how many messages are on the queue you can chose the "currentQueueDepth" column which will show how many messages are on the queue at the time of the sample.
If you have MONQ turned on for the queue you can also use oldestMsgAge to monitor for the length of time the oldest message has been on the queue at the time of the sample.
The documentation for the MQ-QUEUE plugin is located at the following link and contains detailed information on the configuration: https://resources.itrsgroup.com/Netprobe/middleware/mq-queue.html
Related
I have inherited an IMB MQ (V6) system that has multiple brokers. Is there a way to explore everything succinctly ?
i.e. I know what queue managers are running, so without "runmqsc"ing each and every manager, how can i find broker names, listeners, etc ?
There is the Explorer running but again points to knowing the manager and port to have it connect successfully.
For MQ, the dmpmqcfg command can be useful to output your configuration info to a file.
For the broker, try the mqsilist command to list installed brokers and their associated resources.
this webpage may be of help to you:
Performing health checks for WebSphere Message Broker
http://www.ibm.com/developerworks/websphere/library/techarticles/0801_cui/0801_cui.html
To work out which queue managers are running on your machine, use thedspmq command. Then you'll know each queue manager and can runmqsc to each one, or point MQ Explorer to each one, or whatever you need to do next.
I need to send messages to different Queue Managers (different QM name, host-port pairs).
What is the best way to handle this scenario? Do I need to create separate ConnectionFactory for each Queue Manager?
Use Case: Java service which is sending command message to distributed agents (FTE agents). However those agents can listen on different queues on different Queue Managers.
Yes you need to use different ConnectionFactory for each JMS server. You can reuse ConnectionFactory only for various Queues on one Message Broker.
I think you are better of connecting the different queue managers hosting the queues and accessing the remote queues via remote queue definitions created on the queue manager your JMS application is connecting to.
I guess these queue managers are already connected, if you are moving files between the FTE agents.
FTE has the concept of the Command Queue Manager. This node is designated as the one QMgr to which the application should connect when communicating with the FTE agents. If the network has been properly defined, connectivity between all FTE agents and the Command QMgr will be present.
The design is one of the ways in which FTE can enforce security. It is possible on the agent QMgrs for the channel from the command queue manager to be authorized very specifically to a subset of the queues and the messages monitored. The design provides a policy enforcement point. Since the FTE security model is weak to begin with, it is important to try to properly use the security controls that are provided.
This design also means that it is not necessary to manage application service account credentials across all the agent QMgrs.
So, yes, use the Command QMgr for its intended purpose. Have one and only one connection factory and properly design and secure the FTE network using the Command QMgr and its channels as a policy enforcement point.
I'm trying to configure a clustered websphere application server that connects to a clustered MQ.
However, the the information I have is details for two instances of MQ with different host names, server channels and queue manager which belongs to the same MQ cluster name.
On the websphere console, I can see input fields for hostname, queue manager and server channel, I cannot find anything that I can specify multiple MQ details.
If I pick one of the MQ detail, will MQ clustering still work? If not, how will I enable MQ clustering given the details I have?
WebSphere MQ clustering affects the behavior of how queue managers talk amongst themselves. It does not change how an application connects or talks to a queue manager so the question as asked seems to be assuming some sort of clustering behavior that is not present in WMQ.
To set up the app server with two addresses, please see Configuring multi-instance queue manager connections with WebSphere MQ messaging provider custom properties in the WAS v7 Knowledge Center for instructions on how to configure a connection factory with a multi-instance CONNAME value.
If you specify a valid QMgr name in the Connection Factory and the QMgr to which the app connects doesn't have that specific name then the connection is rejected. Normally a multi-instance CONNAME is used to connect to a multi-instance QMgr. This is a single highly available queue manager that can be at one of two different IP addresses so using a real QMgr name works in that case. But if the QMgrs to which your app is connecting are two distinct and different-named queue managers, which is what you described, you should specify an asterisk (a * character) as the queue manager name in your connection factory as described here. This way the app will not check the name of the QMgr when it gets a connection.
If I pick one of the MQ detail, will MQ clustering still work? If not,
how will I enable MQ clustering given the details I have?
Depends on what you mean by "clustering". If you believe that the app will see one logical queue which is hosted by two queue managers, then no. That's not how WMQ clustering works. Each queue manager hosting a clustered queue gets a subset of messages sent to that queue. Any apps getting from that queue will therefore only ever see the local subset.
But if by "clustering" you intend to connect alternately to one or the other of the two queue managers and transmit messages to a queue that is in the same cluster but not hosted on either of the two QMgrs to which you connect, then yes it will work fine. If your Connection Factory knows of only one of the two QMgrs you will only connect to that QMgr, and sending messages to the cluster will still work. But set it up as described in the links I've provided and your app will be able to connect to either of the two QMgrs and you can easily test that by stopping the channel on the one it connects to and watching it connect to the other one.
Good luck!
UPDATE:
To be clear the detail provide are similar to hostname01, qmgr01,
queueA, serverchannel01. And the other is hostname02, qmgr02, queueA,
serverchannel02.
WMQ Clients will connect to two different QMgrs using a multi-instance CONNAME only when...
The channel name used on both QMgrs is the exactly the same
The application uses an asterisk (a * character) or a space for the QMgr name when the connection request is made (i.e. in the Connection Factory).
It is possible to have WMQ connect to one of several different queue managers where the channel name differs on each by using a Client Connection Definition Table, also known as a CCDT. The CCDT is a compiled artifact that you create using MQSC commands to define CLNTCONN channels. It contains entries for each of the QMgrs the client is eligible to connect to. Each can have a different QMgr name, host, port and channel. However, when defining the CCDT the administrator defines all the entries such that the QMgr name is replaced with the application High Level Qualifier. For example, the Payroll app wants to connect to any 1 of 3 different QMgrs. The WMQ Admin defines a CCDT with three entries but uses PAY01, PAY02, and PAY03 for the QMgr names. Note this does not need to match the actual QMgr names. The application then specifies the QMgr name as PAY* which selects all three QMgrs in the CCDT.
Please see Using a client channel definition table with WebSphere MQ classes for JMS for more details on the CCDT.
Is MQ cluster not similar to application server clusters?
No, not at all.
Wherein two-child nodes are connected to a cluster. And an F5 URL will
be used to distribute the load to each node. Does not WMQ come with a
cluster url / f5 that we just send message to and the partitioning of
messages are transparent?
No. The WMQ cluster provides a namespace within which applications and QMgrs can resolve non-local objects such as queues and topics. The only thing that ever connects to a WebSphere MQ cluster is a queue manager. Applications and human users always connect to specific queue managers. There may be a set of interchangeable queue managers such as with the CCDT, but each is independent.
With WAS the messaging engine may run on several nodes, but it provides a single logical queue from which applications can get messages. With WMQ each node hosting that queue gets a subset of the messages and any application consuming those messages sees only that subset.
HTTP is stateless and so an F5 URL works great. When it does maintain a session, that session exists mainly to optimize away connection overhead and tends to be short lived. WMQ client channels are stateful and coordinate both single-phase and two-phase units of work. If an application fails over to another QMgr during a UOW, it has no way to reconcile that UOW.
Because of the nature of WMQ connections, F5 is never used between QMgrs. It is only used between client and QMgr for connection balancing and not message traffic balancing. Furthermore, the absence or presence of an MQ cluster is entirely transparent to the application which, in either case, simply connects to a QMgr to get and./or put messages. Use of a Multi-Instance CONNAME or a CCDT file makes that connection more robust by providing multiple equivalent QMgrs to which the client can connect but that has nothing whatever to do with WMQ clustering.
Does that help?
Please see:
Clustering
How Clusters Work
Queue manager groups in the CCDT
Connecting WebSphere MQ MQI client applications to queue managers
This is very basic question about IBM WebSphere MQ V7.
Regarding the Transmission Queue, my understanding is it is only used with remote queue that resides in the same queue manager. Therefore, if I want to put message to the queue, I need to put it to remote queue.
It is like this.
App --> Remote queue --> Transmission Queue
My question is:
Is it possible to put the message directly into transmission queue like this?
App --> Transmission Queue
--Modified on 2014.03.17 --
I found a way to put message directly into transmission queue. I do not know this is a common use, but in order to do that I needed to prepend MQXQH to the message. I tried and confirmed it works. See the Infocenter reference here.
Do not ever put directly to a transmission queue. It is dangerous if you do not know what you are doing.
You should put your message to a remote queue. A remote queue is not the same as a local queue. A remote queue is simply a pointer to a queue on another queue manager.
Although it is possible to put messages directly on the XMitQ, there is considerable risk in allowing that to occur so most admins will prevent applications from directly accessing that queue. As you have found, it is possible to construct a message with the transmission queue header and behind that a normal message with the MQMD and payload. (This is, in fact, excatly how the MCA works.)
The problem here is that the QMgr does not check the values in the MQMD residing in the payload so you can put mqm as the MQMD.UserID and then address the message to the remote command queue and grant yourself admin access to that remote QMgr.
Security-conscious administrators typically use two security controls to prevent this. First, they disallow direct access to the XMitQ. That helps for outbound messages. More importantly, they set the MCAUSER of their RCVR/RQSTR/CLUSRCVR channels to a non-admin user ID that is not authorized to put messages onto any sensitive queues.
The other issue is, of course, that what you describe completely defeats WMQ's name resolution. By embedding routing into the app, you prevent the administrator from adjusting channel weights, cluster settings, failover and load distribution at the network level. Need to redistribute traffic? Redeploy the code. Not a good plan.
So for security reasons and because you paid a lot of money to get WMQ's reliability - much of which comes from dynamic addressing and name resolution features - coding apps to write directly to the XMitQ is strongly discouraged.
You should not directly be using the transmission queue. Its used by the message channel agent (MCA) as temporary storage when sending messages across to a remote queue manager.
This is distributed queuing - i.e you publish a message to Queue Manager A, and want it routed to a local queue on Queue Manager B. So you define a reference on QM-A referring to the local queue on QM-B. This reference is the 'remote queue definition'.
The remote queue definition specifies the transmission queue name. The transmission queue is bound to the MCA, which in turn knows about the remote QM.
I am a novice with Websphere MQ and require some novice help.
I am using Websphere MQ Explorer to connect to a queue but do not know how to write the connection string. I have all the details (host, port, channel, queue manager name) but do not know how to put them together correctly as a connection string.
Can any help this novice?
Thanks
Here is one way to get you started (assuming your queue manager under default configuration):
Queue Managers->Context Menu->Add Remote Queue Manager
Fill in Queue manager name:
Select Connect directly
Next
Fill in:
Host name or IP Address:
Port number:
Server-connection channel:
Next
Next
If you have a user configured usually mqm user, you will need to tick the "Enable user identification" here and fill in the user/pass here.
Next, Next, Finish.
As you see, you might need to fill in other information such as SSL if you configured it at the target queue manager.
Then you should be able to see the queue manager in the tree. Click on the Queues icon to find the queue you care about.
Hopefully you are using the latest WebSphere MQ Explorer which is now a stand-alone download. You can find it at SupportPac MS0T which is available from the main SupportPac page. There are significant advantages to using that version, including Explorer Plug-Ins for WMQ FTE, WebSphere Message Broker, the MS0P plug-in which parses event messages, and more.
The screen shot below shows the connection dialog in the latest WMQ Explorer. It has separate fields for hostname (or IP address). port and channel. Just plug in the appropriate values and you are good to go!