I was reading some information about the difference between the message channels and the message queues,
I understand that the channel is used for connecting to a queue
manager and not to a queue.
So the channel can retrieve/send message to different queues or just a particular queue? But when a producer needs to place a message into a queue, it specifies the name of the queue and the queue manager, but if that information was specified by the producer is not needed that the channel knows that information, right?
When is has a Publish/Subscribe messaging style, is always used a sender/receiver channel?
A message channel connects together two queue managers. There are various different pairs of channel types that have slightly different behaviours, but all those types which send from one queue manager to the other are the same from the perspective of your question. For the rest of this answer I will use the SENDER-RECEIVER pair.
A SENDER channel will ALWAYS read from one queue - a transmission queue. It is named on the SENDER channel definition. The transmission queue is a safe storage area for the message until it is successfully transmitted to the the target queue manager.
An application connected to the sending queue manager can put messages to many different queues on the target queue manager and they will all, initially, be stored on the transmission queue.
This is possible because the queue manager adds a special header (called a transmission header - MQXQH) to the front of the message while it resides on the transmission queue. This header contains the target queue name and the target queue manager name as provided originally by the message producer. The channel does not know this information, it is provided by the producer.
Once the channel has moved the message across the network to the target queue manager, the RECEIVER channel removes the transmission header and uses the data in it, the queue name and queue manager name, to put the message to the appropriate queue.
In this way a single channel pair can deliver messages to many different queues.
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.
Is it possible to setup an IBM MQ receiver channel to receive messages from two different queue managers with the sender channels named identically. I am looking at a situation where a client wishes to have two queue managers (A and B) able to send messages to the same destination queue manager (C). A and B are setup up in an active / passive cluster setup without shared storage.
It is not only possible to set up IBM MQ Receiver channels to receive messages from two different queue managers, it is recommended to do so.
For example, on QM3 (the receiving queue manager) make the following definition:
DEFINE CHANNEL(TO.QM3) CHLTYPE(RCVR) TRPTYPE(TCP)
Then on both QM1 and QM2 make the following definitions:
DEFINE CHANNEL(TO.QM3) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('qm3-host-name(qm3-port)') XMITQ(QM3)
DEFINE QLOCAL(QM3) USAGE(XMITQ)
Doing this will NOT cause sequence number issues as the state for each running receiver channel instance is keyed off the channel name plus the partner queue manager name, so there will be state for:-
Channel:TO.QM3 from Partner QMgr QM1
Channel:TO.QM3 from Partner QMgr QM2
Both channel instances can be running at the same time quite happily without interfering with each other.
You can see this state by issuing the following command on the receiving queue manager, QM3:-
DISPLAY CHSTATUS(TO.QM3)
I'am trying to understand the topology of queues and exchanges MT creates in RabbitMQ.
I cannot get these two statements:
we generate an exchange for each queue so that we can do direct sends
to the queue. it is bound as a fanout exchange (is it about sending vs publishing?)
control queues are exclusive and auto-delete - they go away when you
go away and are not shared.
What for does MT need to send direct messages? Does this relate to control queues used by MT internally?
There is also no mentioning about dead letter queue, does that imply MT does not support one out of the box?
Oops, looked in a wrong place. It's here.
Michael Aldworth has described this in details in his excellent MassTransit Send vs. Publish blog post.
Essentially, for each MT endpoint, you get a exchange-queue pair, which is named after the queueName parameter value in the endpoint configuration. Topics, at the other hand, are RabbitMQ exchanges named after the message contract full type name.
Publish
You send a message to the topic, meaning to the message type exchange. MassTransit creates binding between the message type exchange and queue-name exchange on start up. In such way subscriptions work on the RabbitMQ levels. Publisher never knows who will be receiving the published message, if anyone at all.
Send
When sending, however, you need to specify the receiver address. By doing this you instruct MassTransit to deliver the message directly to the queue-name exchange. There is no binding between message-type exchange and queue-name exchange involved here. Therefore, the message will be delivered even if there is no consumer for this type of message at the target service. In such case the message will be moved to the deadletter queue (queue-name_Skipped).
i've a question about the DEADQ in MQ. I know that DEADQ has been used when the msg cannot be delived into the target queue, for example queue full or put inhibited like this. But if the client applicatoin connects to QMGR through SVRCONN channel and that target queue is full right now, will the msg sent by client application go to DEADQ or just that put operation would return with failure saying queue full?
if it works as the latter, does it mean the DEADQ not being used for client-server mode, like through SVRCONN channel?
Thanks
The DLQ is used by QMgr-to-QMgr channels because at that point the message has been entrusted to WMQ to deliver and/or persist as necessary. There is no option to directly notify the sending application in the API call that something went wrong. Best the QMgr can do is to send back a report message, if the app has requested it, and if the app specified a reply-to queue.
When an application is connected over a client channel the QMgr can tell the application during the PUT API call "hey, the destination queue is full," and let the application decide the appropriate course of action. Usually that "correct action" does NOT include putting the message onto the DLQ. In fact, routing this type of message to a secondary queue is VERY unusual. Conventional wisdom says it's better for the app to raise an alert than to provision overflow queues.
The one exception to this is when using JMS classes. These will move a poison message (one where the backout count exceeds the BOTHRESH value on the queue) to a backout queue. If the backout queue is not specified or the app is not authorized to it or if it is full, the app will then try to use the DLQ. Again, allowing an app to directly put messages to the DLQ is very unusual and not considered good practice, but it can be done.
With WebSphere MQ, where is a message addressed to a remote queue manager and PUT under syncpoint control stored until MQCMIT is issued?
Messages that are addressed to a remote queue manager resolve to a transmit queue. Which transmit queue they resolve to depends on how the message will be sent to the remote QMgr. The message will resolve locally to either a user-defined transmit queue for a SDR or SVR channel, or it will resolve to SYSTEM.CLUSTER.TRANSMIT.QUEUE for a clustered channel.
For any message that is put under syncpoint, the message is written to the transaction logs and, if the message is persistent, to the queue file. The queue depth increases to reflect that the message is in the queue but the message is not made available to other programs (such as the channel agent) until the COMMIT occurs.
So if your message is going to a clustered queue manager and you PUT under syncpoint, you will see the depth of the cluster transmit queue increase. At that point the message is at least in the transaction log and possibly also written to the queue file. As soon as the message is committed, it becomes available to the channel.