Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
IBM MQ
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Communication== Queue managers communicate with the outside world either through: *'''Bindings''': a direct software connection. Generally faster, but limited to programs running on the same physical host as the queue manager. *'''A network or "client" connection''': applications using a client connection can connect to a queue manager on any other host in the network. The physical location of the queue manager is irrelevant, as long as it is reachable over the network. ===Communication between queue managers=== This relies on a ''channel''. Each queue manager uses one or more channels to send and receive data to other queue managers. A channel is uni-directional; a second channel is required to return data. In a TCP/IP based network, a channel sends or receives data on a specific port. Channel types: *'''Sending channel''': has a defined destination and is associated with a specific transmission queue (the mechanism by which messages are queued awaiting transmission on the channel). *'''Receiving channel''': receives data from any other queue manager with a sending channel of the same name. When a receiving channel receives a message, it is examined to see which queue manager and queue it is destined for. In the event of a communications failure, MQ can automatically re-establish a connection when the problem is resolved. The ''listener'' is the application's network interface to the queue manager. The listener detects connections from incoming channels, and manages the connection of the sending channels to the receiving channels. In a TCP/IP network, the listener will "listen" for connections on a specific port. ===Transmitting data to a queue on another queue manager=== Queue types: *'''Local queue''': represents the location where data is stored awaiting processing. *'''Remote queue''': represents a queue on another queue manager. They define the destination queue, which is one element of the routing mechanism for messages. *'''Cluster queue''': represents a queue which is reachable via any queue manager in its cluster. A message is placed on a remote queue. The messages goes to a temporary storage transmission queue associated with a channel. On placing a message on a remote queue, the message is transmitted across the remote channel. If the transmission is successful, the message is removed from the transmit queue. On receiving a message, the receiving queue manager examines the message to determine whether the message is for itself or if must go to another queue manager. If the receiving queue manager, the required queue will be checked, and if it exists, the message is placed on this queue. If not, the message is placed on the [[dead letter queue]]. MQ has features to manage efficient transmission of data across a variety of communication media. For example, messages can be batched together until a queue reaches a particular depth. ===Ordering=== Although the queue is FIFO, it is ordered based on the receipt in the local queue, not the committing of the message from the sender. Messages can be prioritized, and by default, the queue is prioritized in order of arrival. Queues will only be in sequence of addition if the message is added locally. Message grouping can be used to ensure a set of messages are in a specific order, aside from that, if sequence is critical, it is the application's responsibility to place sequence data in the message or implement a handshaking mechanism via a return queue. In reality, ordering will be maintained in straightforward configurations. ===The log=== The other element of a queue manager is the ''log''. As a message is placed on a queue or a configuration change is made, the data is also logged. In the event of a failure, the log is used to recreate damaged objects and recreate messages. Only ''persistent'' messages are recreated when a failure occursโ"non-persistent" messages are lost. Non-persistent messages can be sent across a channel set to a fast mode, in which delivery is not assured in the event of a channel failure. MQ supports both circular and linear logging. ===Retrieving messages from queues=== Information can be retrieved from queues either by polling the queue to check for available data at suitable intervals, or alternatively MQ can trigger an event, allowing a client application to respond to the delivery of a message.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)