This blog is part of a series that shall assist Integration Developers to properly address non-functional aspects like resource consumption, performance, and reliability. The previous contribution in this series is
Avoid Binding Variables in Groovy Scripts.
This contribution focuses on memory consumption due to very large messages.
Message sizes can greatly vary depending on the integration scenario. While messages are often in the kilobyte range, they can assume sizes of tens or even hundreds of megabytes in some integration scenarios.
When messages, which considerably exceed the expected size, are sent to an Integration Flow, they can drastically increase resource consumption and thus impact other messages, which are being processed by this or other Integration Flows. In the worst case, this results in an
java.lang.OutOfMemoryError, which would interrupt message processing.
In order to mitigate this risk, you can place limits on the size of the message body, and/or message attachments. This is supported for the following adapters as of version 1.1:
- SOAP (1.x)
- SOAP (SAP RM)
- IDoc
The configuration is explained in the official documentation for
SOAP (1.x),
SOAP (SAP RM), and
IDoc adapters, respectively.
The smallest value for a size limit is 1 MB. By default, the limits are set as
- Body Size = 40 MB
- Attachments Size = 100 MB
An empty or zero value means, that no size limit applies to message body and message attachments, respectively.
Once you have configured appropriate limits, and a message is received, which exceeds one or both limits, this message is not accepted for processing, and an error response is returned to the sender. This response is sent with status code
HTTP 413 “Request Entity Too Large”
and the following error message:
An internal error occurred. For error details check MPL ID <value of MPL ID> in message monitoring or use the URL https://<TMN host>:443/itspaces/#/shell/monitoring/MessageDetails/{"messageGuid":"<value of MPL ID>"} to directly access the error information.
The placeholder "<TMN host>" represents the Tenant Management Node for the tenant to which the message was sent. The placeholder "<value of MPL ID>" contains the ID of a Message Processing Log (MPL), which provides details about the violation of the size limits, as illustrated by the following two examples. In both examples, a SOAP (1.x) channel is configured with a limit of 1 MB for both
Body Size and
Attachments Size. In the first example, the size of the message body exceeds the limit configured for the
Body Size. In the second example, the message contains attachments, whose total size exceeds the limit configured for the
Attachments Size.
Example 1:
A large message exceeding the limit for the
Body Size is sent to the SOAP (1.x) channel. Then the sender of the message will receive the above error response, and the MPL will provide the following error information:
LastError = com.sap.esb.size.limiter.SizeLimitExceededException: Message exceeds configured size limit (body 1.0 MB, attachments 1.0 MB). Actual body size was 100.3 MB, attachments size was 0 B)
Example 2:
A message with attachments exceeding the limit for the
Attachments Size is sent to the SOAP (1.x) channel. Then the sender of the message will receive an error response as described in example 1, and the MPL will provide the following error information:
LastError = com.sap.esb.size.limiter.SizeLimitExceededException: Message exceeds configured size limit (body 1.0 MB, attachments 1.0 MB). Actual body size was 150 B, attachments size was 1.9 MB)
By not accepting an unexpectedly large message, overloading of resources and impacts on the processing of other messages through this message can be avoided.
The next contribution in this series is
Avoid Storing Payloads in the Message Processing Log.
