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.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21633353