System considerations for message flow development

Default stack size

When a message flow thread executes, 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 allocated to a message flow thread depends on the platform used.

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

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

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

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 about 2KB of the stack space. A typical message flow can therefore include roughly 250 nodes on z/OS, 500 nodes on UNIX platforms and 500 nodes on Windows. This amount can be higher or lower depending on the type of nodes used and the processing they perform.

Increasing the stack size on Windows and UNIX platforms

You can increase the stack size by setting the MQSI_THREAD_STACK_SIZE environment variable to an appropriate value. When you restart brokers running on the system they will 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 will therefore need a large amount of storage for the stack.

Increasing the stack size on z/OS

Integrator components on z/OS are compiled using the new XPLINKage (extra performance linkage), which adds optimization to the runtime code. However, if the initial stack size is not large enough, then stack extents will be used. 128KB is used in each extent. It is very important that a large enough downward stack size is chosen, because XPLINK performs badly 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 do this, a message flow must be tested using the RPTSTG option with the _CEE_RUNOPTS environment variable. This should be set in the component profile (BIPBPROF for a broker) during the development and test of message flows 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 LE_CEE_RUNOPTS environment variable in the component profile.

When updating the component profile you must stop the component, make the necessary changes to the profile, submit BIPGEN to recreate the ENVFILE and restart the component.

For example, you can change the default values of 50K and 512K in the following line to suit your needs:
export _CEE_RUNOPTS=XPLINK(ON),THREADSTACK(ON,50K,15K,ANYWHERE,KEEP,512K,128K)

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

Note: XPLINK stacks grow downward in virtual storage while the old standard linkage grows upward. To avoid a performance impact caused by switching between downward stack space and upward stack space during runtime, you should 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, you will need to determine and 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 recursively calls the same procedure or function, or when an operator, for example the concatenation operator, is used repeatedly in an ESQL statement.
Related tasks
Optimizing message flow response times
Related reference
Message flows