Stack storage

Default stack size

When a message flow thread starts, it requires storage to perform the instructions that are defined by the logic of its connected nodes. This storage comes from the execution group's heap and stack size. The default stack size that is allocated to a message flow thread depends on the operating system that is used.

Windows platform Each message flow thread is allocated 1 MB of stack space.

Linux platform Each message flow thread is allocated 8 MB of stack space.

UNIX platform Each message flow thread is allocated 1 MB of stack space.

z/OS platform Each message flow thread is allocated 512 KB of downward stack space and 50 KB of upward stack space.

In a message flow, a node typically uses 2 KB of the stack space. A typical message flow can therefore include 250 nodes on z/OS, 500 nodes on UNIX systems and 500 nodes on Windows. This amount can be higher or lower depending on the type of nodes used and the processing that they perform.

Increasing the stack size on Windows and UNIX systems

You can increase the stack size by setting the MQSI_THREAD_STACK_SIZE environment variable to an appropriate value. When you restart brokers that are running on the system, they use the new value.

The value of MQSI_THREAD_STACK_SIZE that you set is used for every thread that is created within a DataFlowEngine process. If the execution group has a large number of message flows assigned to it and you set a large value for MQSI_THREAD_STACK_SIZE, the DataFlowEngine process therefore needs a large amount of storage for the stack.

Increasing the stack size on z/OS

Integrator components on z/OS are compiled using the XPLINKage (extra performance linkage), which adds optimization to the runtime code. However, if the initial stack size is not large enough, then stack extents are used. 128 KB is used in each extent. Ensure that you choose a large enough downward stack size because the performance of XPLINK degrades when stack extents are used.

To determine suitable stack sizes, a component administrator for z/OS can use the LE (Language Environment®) Report Storage tool. To use this tool, you must test a message flow using the RPTSTG option with the _CEE_RUNOPTS environment variable. Set this option in the component profile (BIPBPROF for a broker) during the development and test of message flows that are intended for production. For example:
export _CEE_RUNOPTS=XPLINK\(ON\),RPTSTG(ON)
You can then override the default values for the stack sizes on z/OS by altering or adding the _CEE_RUNOPTS environment variable in the component profile.
When you update the component profile, perform the following steps:
  1. Stop the component.
  2. Make the necessary changes to the profile.
  3. Submit BIPGEN to re-create the ENVFILE.
  4. Restart the component.
For example, you can change the default values of 50 K and 512 K in the following line to suit your needs:
export _CEE_RUNOPTS=XPLINK(ON),THREADSTACK(ON,50K,15K,ANYWHERE,KEEP,512K,128K)

When you use RPTSTG, it increases the time that an application takes to run. You should therefore use it as an aid to the development of message flows only, and not in your final production environment. When you have determined the correct stack sizes needed you should remove this option from the _CEE_RUNOPTS environment variable.

XPLINK stacks grow downward in virtual storage while the standard linkage grows upward. To avoid a performance impact caused by switching between downward stack space and upward stack space during run time, compile user-defined extensions using the XPLINK option where possible. If your message flow uses user-defined extensions that have been compiled with the standard linkage convention, set a suitable value for the upward stack size.

Determining the correct stack size

In WebSphere Message Broker, any processing that involves nested or recursive processing can cause extensive usage of the stack. For example, in the following situations you might need to increase the stack size:
  • When a message flow is processing a message that contains a large number of repetitions or complex nesting
  • When a message flow is executing ESQL that calls the same procedure or function recursively, or when an operator (for example, the concatenation operator) is used repeatedly in an ESQL statement
Related concepts
Stack storage
JVM heap sizing
Configuring JVM options
Related tasks
Optimizing message flow response times
Related reference
Message flows