Comments (17)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 akainz commented Permalink

Hi this article inpired me to my blog post at
In it I look at quick fixes for out of memory situations in Message Broker. Any comments or additional remedies are greatly appreciated.

2 SteveWebb commented Permalink

Thanks for the comments and we're glad this article inspired you to create some additional resources on your blog! Thanks for the link.
Vivek (the author of the original post) will respond to your comment soon. - Steve

Disclaimer note: The previous comment contains a link to an external (non-IBM) blog site; see our disclaimer statement at the top of our blog regarding external Web sites.

3 vivekgrover commented Permalink

@akainz, Thanks for your interest and comment. When you have a DataFlowEngine crashing with out of memory condition, the quick approach to remedy this should be to find ways to reduce the load on the DataFlowEngine that is crashing. This load could be in terms of excessive number of message flows using a lot of JVM heap or excessive message processing done by the message flows resulting in DataflowEngine JVM heap getting exhausted and eventually crashing the DataFlowEngine.
A quick fix could be to isolate the message flow responsible for this behavior into its own Execution Group. If there are multiple message flows responsible for this situation then, you can stop the message flows or distribute the message flows from this Execution Group into multiple Execution groups.
Additionally, the JVM heap for the DataFlowEngine could be tuned. In the long run, the message flow/s should be reviewed and analyzed to see the high JVM consuming points (in terms of any native java nodes or user defined plugin nodes or Java compute nodes)

4 timo commented Permalink

Hi. it lets me understand the internals of DataFlowEngine and JVM. thank you!

5 vivekgrover commented Permalink

Thank you.

6 DaveCrighton commented Permalink

I think it's important here to note that the clearMessage() example is actually even more insidious than a leak of objects on the java heap because native memory is allocated for each MbMessage. The MbMessage object is actually very small on the Java side but can hold out substantial amounts of native heap. Therefore it's possible for the MbMessage to never be garbage collected resulting in native memory not being freed up. clearMessage actually free's up the native side objects so you don't have to wait until gc time. Of course when you run out of native memory you dont even get a Java OutOfMemory error which usually has a stack trace that gives you a good idea of where the problem is, instead you end up with an abend (most likely with malloc or newHandler in the stack backtrace).

7 vivekgrover commented Permalink

Thanks Dave for your comments.
1. It is possible for the MbMessage to never be garbage collected, since its so small, which may result in native memory not being freed up at all. Using the clearMessage() method does free up the native side objects and you don't have to wait until garbage collection is driven.

2. It is important to note that when you run out of native memory you dont even get a Java OutOfMemory exception but get an abend (most likely with malloc or newHandler in the stack backtrace)
It is advisable to use the clearMessage() method.

8 anannya_joshi commented Permalink

I have a message flow which uses a file input node, a compute node and and file output node. I am picking up XML files from an directory and converting them into another format. But, somehow, I am not able to to process files more than 20MB..
I see the "Failed to allocate memory" error in the abend files. I am not sure which parameter of the JVM heap should I reduce or increase. Would you please suggest?
current params are:
minjvmheap = 32 mb
maxjvmheap = 256mb

9 SteveWebb commented Permalink

(posting Vivek's response) @anannya_joshi You can try increasing the value of jvmMaxHeapSize for the DataFlowEngine. However, please note that we can't provide "support" through the blog and so for any further queries like this, please open a PMR through the SR tool using the following link -

10 jeter commented Permalink

What would be the mqsichangeproperties to change the GCPolicy to GENCON

11 vivekgrover commented Permalink

@jeter - Thank you for the comment. Since your concern is quite specific, it is best to pursue this through the support center using the SR tool here:
I see that you have already opened an SR request, so we will work on the issue through the support center.

12 7F4F_Michael_Blomberg commented Permalink


Thx for great info about jvm in WMB.
I have one consideration however..
In jvms you normally can tune your GC. Both minor and major GC can be tuned also generations in the jvm where the java objects "live" can be tuned.
No examples in this article of how to pass jvm tuning parameters in WMB. Is it possible to do? Havent found anything in the docs about this.

13 vivekgrover commented Permalink

Thanks Michael, you can tune the DataFlowEngine JVM for these parameters by passing them to the broker using the environment variable: IBM_JAVA_OPTIONS or by running the command mqsichangeproperties on the ComIbmJVMManager object of the DataFlowEngine.

14 7F4F_Michael_Blomberg commented Permalink

Ok thx!

But is there any examples of an common tuning of GC in WMB jvms? The most vendors that supply an jvm often provides an setup for this. To have an common optimized tuned GC.

15 vivekgrover commented Permalink

Hi, WMB references JRE provided by IBM or Oracle. Typically, you should be referencing the JRE provider's documentation for these options. You can check the following document that talks about tuning GC in IBM JRE -
I also came across the following WSTE link -
Hope that helps.