Starting up |
When Postcard starts, it checks what queue managers exist on this computer, and initializes the sign-on dialog accordingly (if there are no queue managers at all, it will prompt you to install the default configuration).
Postcard uses the JMS call |
Receiving messages |
All the time Postcard is running, it polls a queue called postcard for incoming messages from other Postcards. (If there is no queue called postcard, Postcard will attempt to create one). When Postcard starts running, it creates a JMS QueueReceiver object for the local postcard queue, providing as a parameter a selector string which filters the messages to be received from the queue by the Correlation Identifier (CorrelId field). The selector string defines that the postcard client should only receive messages where the CorrelID field matches the nickname of the user. The words from the message data are then presented in the JMS Postcard window. |
Sending messages |
If you did not enter a computer name in the On: field, then Postcard assumes the recipient is on the same queue manager. If you did enter a name, postcard checks for the existence of a queue manager with this name - first using the exact name supplied, and then using a prefix in the same format as that created by the default configuration.
In both cases, it will issue a
Finally it builds a JMS BytesMessage from your nickname and the words
you typed in, and executes |
How the postcards get there |
When other instances of Postcard on this computer are using the same queue manager and queue, the messages are simply being put and got from the one queue. This does, however, verify that the WebSphere MQ code installed on this computer is configured and working correctly. For the Postcard to send to another queue manager, a connection must exist to it. This connection will exist because either both queue managers are members of the same cluster, or you have explicitly created a connection yourself. Postcard can therefore assume that the queue manager will be connectable, and simply connects to it, opens the queue and puts a message, as already described, leaving all the work of getting the message there to the WebSphere MQ cluster code. In other words, Postcard uses only the one piece of code for putting the message, and does not need to know whether or not the message is going to another computer. In Postcard, when session.createSender("postcard") is called, the cluster code checks the repository to find the other queue manager, and to check that the queue exists, and throws an exception if this was not possible for any reason. When queueSender.send(theMessage) is called, the cluster code opens a channel to the other queue manager (creating it if necessary) and sends the message. The channel may be discarded afterwards, if the cluster optimizing code doesn't need it. If the queue managers are on different computers, that is all handled by the cluster code. |
Tidying up undeliverable messages |
If you sent a Postcard to "John", but never ran a Postcard with the nickname "John", the message would sit on the queue for ever. To prevent this, Postcard sets the Message Lifetime (Expiry) field in the Message Descriptor (MQMD) to 48 hours. After that time, the message will be discarded, wherever it may be (possibly even still in transmission). |
Please send your comments on the help and books to idrcf@hursley.ibm.com
(C) IBM Corporation 1996, 2002. All Rights Reserved