IBM Support What's New?

Memory usage by repeated readString method calls to get MQ messages

Technote (troubleshooting)


You have a WebSphere MQ Java™ application which is handling large messages. Your messages have 50 fields in the user header and the application reads those strings using the readString method 50 times repeatedly. If the size of message is small, no problem will appear. However, if the size of the message is large, when calling the readString method, the heap (whose size is almost the same as the message object) will be consumed on every call. The total consumed heap size will be larger than the message size. As a result, you are not be able to get the expected throughput in that process due to Garbage Collection.


ReadString method was implemented in a way such that the garbage collector was not able to run.

Resolving the problem

It is necessary for the ReadString method to take a copy of the data in the buffer for conversion purposes. This results in each run of ReadString allocating enough memory to store the contents of the message.

This is working as designed.

The problem occurs from misuse of the readString method. It is inefficient to use the readString method to repeatedly read in one character at a time, because such a tight loop does not allow the Garbage Collector to run, thus causing memory usage to build up.

To avoid the problem there are several options:
1. Add a delay each time the readString is called in the loop to allow time for the garbage collector to run.
2. Instead of using the readString method to read in a character at a time use the readChar method.
3. Avoiding the use of the loop altogether by using the readString method in the following fashion:
buffer_str = getMessage.readString(getMessage.getDataLength());

Historical Number

41403 108 760

Product Alias/Synonym


Document information

More support for: WebSphere MQ

Software version: 6.0, 7.0, 7.0.1, 7.1, 7.5

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

Reference #: 1113379

Modified date: 2013-03-28