Burst mode

Use of burst mode makes it possible to take advantage of batch processing efficiencies for single transaction processing use cases. Aggregating events relating to a batch of transactions reduces overhead because there are fewer database and IBM® MQ commit calls.

Burst mode can be enabled on any input channel where it is possible to proactively get the next message from within a message flow. As an example, when using IBM MQ as an input, the physical transmission flow is driven by an MQInput node. It is possible, after processing the IBM MQ message, to go back and get the next message using an MQGet node. Using this technique, the physical transmission flow can get and process a group of single messages in the same unit of work. Doing this allows the Send Event API call to aggregate these events where possible.

To enable burst mode for a channel:

Implement a transmission wrapper that is burst mode aware.
Include burst mode settings on the channel definition.
Review event metadata as part of a design for aggregation.

An example of a transmission wrapper that supports burst mode is shown in the following figure.

Figure 1. A sample transmission wrapper supporting burst mode

Burst mode is configured for a channel by using the parameters setting, which is the PARAM column in the CHANNEL table. Parameters has a comma delimited, tag=value format. The following table shows the settings that are supported for burst mode:

Table 1. Burst mode settings
Parameter name	Description
BURST_LIMIT	The maximum number of messages to read in a unit of work
BURST_WAIT	The maximum time, in milliseconds, to wait for the next message
BURST_MAX_LATENCY	Optional The maximum latency, in milliseconds, that any message can have. Overrides BURST_WAIT if present.

Typically, a good value for BURST_LIMIT is the aggregation threshold for the E_MpInTxnMapped event, which is usually set to 100. Therefore, an example of suitable values for the burst mode parameters might be:

BURST_LIMIT=100, BURST_WAIT=50

Also, consider the maximum processing latency for the first message because, in a worst case scenario, messages could repeatedly arrive before the BURST_WAIT timeout. The message processing latency is:

BURST_LIMIT * BURST_WAIT

Maximum processing latency can be assigned a hard limit by using the optional BURST_MAX_LATENCY parameter, which overrides the BURST_WAIT parameter when set:

BURST_LIMIT=100, BURST_WAIT=0, BURST_MAX_LATENCY=5000

It is also possible to define a channel to allow burst but with no wait:

BURST_LIMIT=100, BURST_WAIT=0

Note: Burst mode may not be suitable for all input channels. Consideration must be given to the business case being served on a channel in specific relation to latency of processing response. Some channels may receive very few messages spread over a whole day; other channels may be subject to periodic bursts of messages.