Can somebody help to understand the basic of these 3 queues with example.when do we use all 3
Perhaps a more simple explanation: Think of a local queue as a queue which exists on the queue manager it is defined.. you can PUT and GET messages off a local queue. A remote queue is like a pointer to a queue on another queue manager which is usually on different host. Therefore messages can be PUT to it (and they will usually arrive on a local queue at that remote host) but you cannot GET messages from a remote queue.
Simply put, a queue manager only ever hosts messages on local or transmition queues on that queue manager. If you want to go to another queue manager, you can use definitions which tell the queue manager that the 'put' is running on, how to route the message to a destination queue manager - however this ends up with a message on a transmit queue which is then picked up and sent down a channel towards that destination. Alias queues are just an opportunity to use a different name for another queue. Remote queues are definitions on one queuemanager with information about where the message should be routed.
MQ documentation:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.explorer.doc/e_queues.htm
Another description:
https://www.scribd.com/doc/44887119/Different-Types-Queues-in-Websphere-MQ
A queue is known to a program as local if it is owned by the queue manager to which the program is connected; the queue is known as remote if it is owned by a different queue manager. The important difference between these two types of queue is that you can get messages only from local queues. (You can put messages on both types of queue.)
References:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.0.1/com.ibm.mq.csqzal.doc/fg10950_.htm
https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.explorer.doc/e_queues.htm
An application which is connected to a local QueueManager which host a queue, So that queue will be local queue for that application. An application which is connected to a QueueManager which is located remotely and that host a queue that queue will be remote queue. we should always keeps in mind that we always read the message from the local queue. A message put on the remote queue, will be routed to local queue through the object defined on the local queue thrugh the channel and the transmission queue.
Related
I currently have an XMIT queue with a SDR channel pointed to a QREMOTE. In a scenario where either the local or remote channels are down, I would like to forward the messages on the XMIT queue to the DLQ. It appears that in this scenario, messages remain on the XMIT queue until the channel is reestablished. Is it possible to do this?
I'm thinking not. From an ibm red paper: http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf
A transmission queue is a local queue with the USAGE(XMITQ) attribute
configured. It is a staging point for messages that are destined for a
remote queue manager. Typically, there is one transmission queue for
each remote queue manager to which the local queue manager might
connect directly. If the destination is unavailable, messages build up
on the transmission queue until the connection can be successfully
completed. Transmission queues are transparent to the application.
When an application opens a remote queue, the queue manager
internally creates a reference to the relevant transmission queue and
messages are put there.
I have two machines - Machine 1 and Machine 2. Machine 1 has one queue manager QM1 and a broker(integration server) BR1 and Machine 2 has one queue manager QM2 and a broker(integration server) BR2 . I want to make a cluster between QM1 AND QM2. I had created a remote cluster queue named INVENTQ in QM2 .The problem is that I am able to successfully post any message on any queue manager and I am able to see the corresponding message on INVENTQ in QM2 . But I want the architecture to be in such a way that I am able to receive the message from the queue from any of the queue managers in addition to the queue manager in which the queue INVENTQ is created i.e QM2 . Can anybody guide me in this ?
MQ does not have a 'remote get' capability - ie you cannot use local bindings to a queue manager and get a message from another queue manager. If you want to do this, you need to use client bindings to go to the queue manger where the message resides directly.
At MQPUT time, a decision has to be made (on the putting queue manager), where to forward the message to (e.g. which local queue, or which transmission queue to pass it to another queue manager).
In a cluster setup, if you have a queue defined on one queue manager and put it the cluster, anyone from any of the clustered queue managers can put to it as though it was a local queue. However their MQPUTs result in the message arriving (via the cluster channels), onto the one particular instance. Therefore from a different queue manager whilst you can put the message to the queue, you cannot get it.
You could have a queue with the same name defined on multiple queue managers and clustered, as per #JoshMc's suggestion, but this means that at MQPUT time, the message is routed to one, and only one, instance of that queue - if it was routed to the remote queue manager clustered definition you still would not be able to get it from the local queue manager. Imagine you had a cluster of 3 qmgrs. You can create a clustered queue called 'FRED' in 2 of them. All of them can put to FRED - but 2 of them will default to put to their local queue only (unless you set CLWLUSEQ=ANY), the other will (usually) alternate between the 2 remote instances. Each queue will definitely have different messages on.
https://www.ibm.com/developerworks/community/blogs/messaging/entry/Undestanding_on_MQ_Cluster_Work_Load_Management_Algorithm_and_Attributes?lang=en
Looking at the sample codes it seems I need queue manager and queue name to setup MQ through code. What is difference between those and where I can get those values from? Any suggestion?
MQTopicConnectionFactory cf = new MQTopicConnectionFactory();
// Config
cf.setHostName("localhost");
cf.setPort(1414);
cf.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
cf.setQueueManager("QM_thinkpad");
cf.setChannel("SYSTEM.DEF.SVRCONN");
MQTopicConnection connection = (MQTopicConnection) cf.createTopicConnection();
MQTopicSession session = (MQTopicSession) connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
MQTopic topic = (MQTopic) session.createTopic("topic://foo");
MQTopicPublisher publisher = (MQTopicPublisher) session.createPublisher(topic);
MQTopicSubscriber subscriber = (MQTopicSubscriber) session.createSubscriber(topic);
You connect to a queue manager which may host many different queues. So yes, an application generally needs access to a queue manager and then specific queues on that queue manager. I suggest you can look at the Stack Overflow info for the websphere-mq tag to help get you started. The names of those objects should be known by your application architect/developer or can be confirmed with the MQ admin.
A Queue is a container for messages. Business applications that are connected to the Queue Manager that hosts the queue can retrieve messages from the queue or can put messages on the queue. We have difference types of Queues as follows:
Local Queue: A local queue is a definition of both a queue and the set of messages that are associated with the queue. The queue manager that hosts the queue receives messages in its local queues
Remote Queue: Remote queue definitions are definitions on the local Queue Manager of queues that belong to another queue manager. To send a message to a queue on a remote queue manager, the sender queue manager must have a remote definition of the target queue.
Alias Queue: Alias queues are not actually queues; they are additional definitions of existing queues. You create alias queue definitions that refer to actual local queues but you can name the alias queue definition differently from the local queue (the base queue). This means that you can change the queues that an application uses without needing to change the application; you just create an alias queue definition that points to the new local queue.
Source
Before going to connect Queue, we must start a queue manager.The queue manager has a name, and applications can connect to it using this name. The queue manager owns and manages the set of resources that are used by WebSphere MQ.
Page sets that hold the WebSphere MQ object definitions and message data
Logs that are used to recover messages and objects in the event of queue manager failure
Processor storage
Connections through which different application environments (CICS®, IMS™, and Batch) can access the WebSphere MQ API
The WebSphere MQ channel initiator, which allows communication between WebSphere MQ on your z/OS system and other systems
Source
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.
We have 2 MQ Queue Managers, and one WAS server. We need to send message from QM01 to QM02 and then from QM02 to WAS server.
For doing this we have built a sender channel between QM01 and QM02, message is placed over a remote queue which has a definition of another remote queue for the WAS Service Integration Bus queue.
Is there any harm in sending message as following;
Remote Queue on QM01 ==> Remote Queue on QM02 ==> Queue on SI
Bus on WAS
Yes, this is a perfectly valid method of hopping messages from one queue manager to another, especially if the queue managers are not clustered. There is no harm to the message or the environment with this approach, though it does has a little more administrative overhead as opposed to a cluster-based solution.