IBM Support

Behavior of SLM action changes when an on-error action is added to a processing rule

Troubleshooting


Problem

When you add an on-error action to a processing rule, an SLM action with the greater-than algorithm does not adhere to the configured settings. This behavior occurs even though the same SLM policy works before the addition of the on-error action.

Symptom

Review the count of the accepted and rejected messages.

For illustrative purposes, assume a constant stream of messages at one per second for cases 1 and 2. The SLM action has the following configuration:

  • Interval length is 6 seconds
  • Interval type is moving
  • Algorithm is greater than
  • Threshold type is count all
  • Threshold level is 4

The difference between the two cases is whether the processing rule contains the on-error action. In case 2, all messages are counted by the on-error action as they are detected. Because all messages are counted and the length is larger than the level, all messages after the first 4 messages fail.

Based on the scenario, the calculation formula is: 1 > 4/6. Where 1 is the message rate/second, 4 is the threshold level, and 6 in the interval length.

The following table shows the 12 seconds for both cases.
Time
Case 1: without on-error action
Case 2: with on-error action
Pass or Fail
Count logic
Pass or Fail
Count logic
1
Pass
0 of 4 in 6 seconds
Pass
0 of 4 in 6 seconds
2
Pass
1 of 4 in 6 seconds
Pass
1 of 4 in 6 seconds
3
Pass
2 of 4 in 6 seconds
Pass
2 of 4 in 6 seconds
4
Pass
3 of 4 in 6 seconds
Pass
3 of 4 in 6 seconds
5
Fail
4 of 4 in 6 seconds
Fail
4 of 4 in 6 seconds
6
Fail
4 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
7
Pass
3 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
8
Pass
3 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
9
Pass
3 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
10
Pass
3 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
11
Fail
4 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds
12
Fail
4 of 4 in 6 seconds
Fail
5 of 4 in 6 seconds

Cause

In this case the On Error action, when triggered, sets the transaction as Processed. Since this transaction is Processed, it increments the SLM count. This configuration creates a situation where the SLM policy triggers the On Error action. Since the On Error action 'catches' this transaction, it is considered processed but still increments the SLM count for rejected transactions.

Resolving The Problem

There are various ways to resolve this issue.

Remove the On Error action


    The On Error action in this case is redundant.

    The cancel error mode stops the current processing rule and trigger a selected error rule. You can reproduce this behavior with a specific match action on the error rule. The match can be made on any criteria to identify the Error Rule or can be matched against a specific error code.The DataPower error code to set is 0x02430001: Message Throttled.

    The alternative and continue error modes are not appropriate in this context. The SLM throttle is nullified for these modes.


Use the token-bucket algorithm
    The token-bucket algorithm takes a token when one is available. Although the On Error action causes the message to count as Processed, the token-bucket algorithm cannot take a token from an empty bucket. If the burst limit is less than the threshold value, the algorithm acts like greater than. The equivalent SLM configuration to the above example is:
    • Interval length is 6 seconds
    • Interval type is moving
    • Algorithm is token-bucket
    • Threshold type is count all
    • Threshold level is 4
    • Burst limit is 4

    With this configuration, the SLM action with an On Error action functions as Case 1.

[{"Product":{"code":"SS9H2Y","label":"IBM DataPower Gateway"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"General","Platform":[{"code":"PF009","label":"Firmware"}],"Version":"4.0.2;5.0.0;6.0.0;6.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21633353