Acknowledgement Messages in IBM MQ Series (Websphere MQ)

We know that IBM MQ Series is MOM i.e. Message Oriented Middleware which means that applications located at remote locations communicate across networks communicate with each other by sending messages to each other through MQ.

In this article I assume that the reader has adequate knowledge about communication between applications in a distributed architecture using Websphere MQ.

Obviously, this is a disconnected approach. In other words, an application A which sends messages to another application B located in some remote system does not wait for the application B to receive the messages. Application A just puts the messages into the local remote queue definition of the MQ and proceeds with its other activities. Later MQ forwards this message to its local queue in the remote system where the application B is located and after that the application B picks up the message from the local queue of its MQ. (See Image Below)

 Now there might be situations when the distributed architecture is prepared where in application A needs to be ensured that the message sent by it has reached application B. In an asynchronous communication like above there is no way to ensure this immediately when the message is put into MQ of local system by application A.

The failure scenarios here where message does not reach application B might be like:

*  Network connection between the two systems is down.
*  The corresponding queue in remote system is not present or is full.
*  Application B is not running in remote system.
*  MQ is not running in the remote system. MQ Server/ queue manager might be down, etc.

In all these situations it might become necessary to notify application A about the success or failure in message delivery to application B. IBM MQ has an option to achieve this where in the application A could be notified of successful  delivery of messages. These messages which denote the message delivery success are called acknowledgement messages.

To summarize, an application (here A) when it puts messages into MQ can also request MQ to send acknowledgement messages to it (here application A) once the message has been delivered to MQ in remote system or to remote application (here application B).

TYPES OF ACKNOWLEDGEMENT MESSAGES:

As you can observe, there are two types of acknowledgement messages:

* COA – Confirmation On Arrival
* COD – Confirmation On Delivery

COA are those acknowledgement messages which are sent back as soon the message is received by the MQ in the remote system. These type of acknowledgement messages can be requested for when it is sufficient to know the successful delivery of messages to the remote system without having to worry about whether the applications in remote system will pick up the messages from their MQ or not.

COD are those acknowledgement messages which are send back only after the message is picked up from the remote MQ by the destination application (in this case application B). These type of acknowledgement messages are required when the source application (here A) has to know that the message has reached the intended target application (in this case B).

Whether to use COA or COD depends on the architecture of your distributed system.

Now how do we tell MQ that we want acknowledgement messages to be sent back?

Well, when you request for a COA or a COD of a message, you also have to specify the Reply-To-Queue Manager and Reply-To-Queue headers of the message. These have to be the queue manager and queue in the remote system, so that the remote MQ puts the acknowledgement messages (COA or COD) into this reply to queue of the reply to queue manager. The reply to queue will usually be a remote queue definition which points back to a local queue of MQ in the system where the application A is residing. Application A will pick up all acknowledgment messages from this local queue.

Hence, before you start sending messages to an application B from an application A by requesting acknowledgement messages, you will first have to setup queues for the acknowledgement messages to arrive in the reverse direction. Note that acknowledgement messages flow in the opposite direction of their messages. So in our case, you need to set up remote queue definition in a queue manager in the system where application B is running and have this remote queue definition to point to a local queue in a queue manager running in the system where application A is running. Then when you send messages from application A to B you need to specify this remote queue definition as the reply-to-queue and its queue manager as the reply-to-queue manager.

Now considering that the acknowledgement messages have arrived back to our system containing application A, how do we know as to which acknowledgement messages belongs to which message sent?

Well, we know the concept of a message header called Message ID in MQ. Each message in MQ is identified by a unique identifier which is stored in the message’s message id header. What MQ does when it sends an acknowledgement message is that, it copies the message id of the original message into the the correlation id field of the acknowledgement message. So, by comparing the message id of the sent message and correlation id of the received message we can identify the original message of an acknowledgement message.

WHAT TO RECEIVE BACK?

Regarding the contents of the acknowledgement messages, we can specify one of the following three options to be contained in an acknowledgement messages.

*   We can specify that we want only the message headers of the original message to be sent back in an acknowledgement message. When all we want is the acknowledgement, we can use this option as this will save bandwidth and space as the contents of the original message will not be sent back with the acknowledgement message in this case.
*  OR we can also specify initial n bytes of the original message to be sent back in the acknowledgement message along with the headers of the original message
*  OR we can even specify the entire original message to be sent back in the acknowledgement message.

C# and Garbage Collection

As we know Garbage Collector in .Net is indeterministic which means that we can never be sure when the garbage collector be invoked (of course, unless and until we explicitly invoke it) .

Now there might be scenarios in which we need to release certain resources held by an object (like a database connection) once the object is no longer in use.

We have destructors in C#. But unlike destructors in C++ which are automatically called when an object is in no longer in user (by using delete operator), in C# destructors are nothing but finalize methods in disguise, with a call to base class’s finalize method.

As we know, finalize method is called during garbage collection by garbage collector. Hence, we cannot rely only on C# destructors to explicitly release resources as finalize methods on objects may never be called altogether (if the program terminates abnormally) or might be called only when the program terminates (in a normal way).

Hence it is always a good practice to implement IDisposable interface in such cases and to write code to release resources explicitly in the Dispose() method.

We know that the Dispose method of a class has always to be called by the developer explicitly when an instance of that class is no longer in use. Now, what if the developers who use our class forget to call the Dispose() method? Hence, it is also good practice to write the same code in C# destructor too, so that at least the garbage collector will release the resources, whenever it is invoked (if at all it gets invoked!!)

Now what if the developer also calls the dispose() method and garbage collector also gets invoked and calls the finalize method on such objects. Well, in that case garbage collector might get run time exceptions while calling finalize method as the Dispose() method would have already released the resources held by the object.

Well, we know that the Garbage Collector ignores any exceptions which occur while calling a finalize method on an object being garbage collected and will terminate the finalize method execution. But we should remember that, calling finalize methods on objects during garbage collection is a costly process and so are exceptions.

So we should ensure that if dispose() method is called on an object then garbage collector does not invoke finalize method on that object. This could be achieved by calling System.GC.SuppressFinalize() method at the end of Dispose() method. SuppressFinalize() tells the Garbage Collector not to call finalize method on that object.

Another interesting feature in C# related to Garbage Collection is the using keyword. Few know that there is another using keyword in C# other than the one used to import namespaces.

This second using keyword is used to define the scope of an object implementing the IDisposable  interface. What this does is that it automatically calls the Dispose() method when the object goes out of the scope defined in the using block. This means that the developer need not call Dispose() method explicitly. All he needs to do is to define the scope of the object.

Here is an sample code snippet.

SqlConnection con = new SqlConnection();
using (con)
{
//your code goes here
}

In the above example as soon as the execution reaches the closing braces, Dispose() method is automatically called. Note that using keyword can be applied only to those objects whose class implements the IDisposable interface.

Secrets of Virtual Memory / Swap File

In a multi-tasking Operating System like Windows, one can open as many as applications one needs and work simultaneously on them. For instance, you might be surfing the internet in your web browser and at the same time you can also have your favorite mp3 songs being played in your favorite media player and also in the background have an FTP client uploading your website to he server.

In such situations where you have multiple applications and too much of data occupying the physical memory of the system, quite often the physical memory i.e. RAM in your system becomes insufficient to store all the current data being used. To overcome this physical memory shortage, the operating system makes use of a certain amount of space on the hard drive to substitute for the deficiency of RAM. This part of memory of the hard drive which is used as a substitute for RAM is called the Virtual Memory.

What the operating system does in the virtual memory is, it creates a large file called the swap file which contains all the data which theoretically should have been in the RAM. In Windows, the name of the swap file is Pagefile.sys and can be found as a hidden file in the root of all the drives which have virtual memory allocated in them.

Note here that the difference between swap file and virtual memory is that the virtual memory is the complete block of memory allocated for the purpose of trying to substitute for RAM deficiency and swap file is the amount of the virtual memory currently being used by the operating system in the form of a system file. A swap file may or may not be occupying the entire virtual memory.

Since the swap file is used as a substitute for RAM, the contents of the file are volatile in nature even though the file itself resides in the hard drive. In other words the contents of this file are lost once the system is shutdown, and new contents arrive as soon as your operating system gets loaded. But, finally how the contents of the swap file are handled depends on the architectures of the individual operating systems. By the way, swap file is called so because, the contents of the swap file are always continuously being swapped between the swap file and system RAM.

It is also to be noted here that even though virtual memory is used as a substitute for system RAM it is in no means as efficient as RAM in terms of speed, as the speed of the virtual memory again depends on that of hard drive as it is located in the hard drive. So, if your system is slower because of inefficient RAM, then to increase its speed increase the physical memory i.e. RAM of the system instead of going for a hard disk with a greater capacity to have more virtual memory.

The performance of your system can come down heavily if the swap file is greatly fragmented in the drives. This usually happens when the operating system itself is managing the virtual memory. A better way out in this case would be to manually allocate a large amount of space on the hard drive for the virtual memory thereby reducing chances of swap file fragmentation. Also, completely disabling the virtual memory in your system may cause your system to slow down heavily and in the worst case might also prevent your system from booting. It is always strongly advised that only technically qualified and knowledgeable persons manage the virtual memory settings.