This blog is part of a series that shall assist Integration Developers to properly address non-functional aspects like resource consumption, performance, and reliability. This contribution relates to Groovy scripts, as they are used in the Script step of Integration Flows. It focuses on issues to improve the message processing reliability. The previous contribution in this series is
How to Guard Against Huge Messages. The next one
Often developers decide to log the message body in the message processing log as an attachment to be able to inspect the body in the Message Monitoring. Consider the following code in an integration flow script step:
def messageLog = messageLogFactory.getMessageLog(message)
def body = message.getBody(String.class)
messageLog.addAttachmentAsString(“a huge one”, body, “application/json”)
return message
Availability
Writing huge data (like the body of a message) in the message processing log on a general purpose should be used with care, because it could compromise the availability of the whole integration scenario. When the data to store is huge, the
additional memory footprint required for logging the data might even cause a
java.lang.OutOfMemoryError. Ultimately the
OutOfMemoryError would interrupt both the logging and the message processing.
Resource Consumption
The memory and CPU time are shared by the message processing and monitoring. The more memory and CPU time is required for the monitoring aspects, the less remains for the real job - the message processing or routing.
Storing the payload in the message processing log can cause excessive load on the storage, especially for large messages and high throughput.
Recommendations
- Consider using the message tracing feature (currently only available in the Eclipse-based tooling) for debugging purposes, instead of logging the message payload in the message processing log as attachment*, because:
- the message tracing can be switched on/off on demand without modification of the integration flow
- it does not utilise any resources when switched off
- If an exceptional case requires to write the message payload into the message processing log as attachment, consider only writing it in error cases (e.g. write the body of a HTTP response in error case).
- For maintainability reasons, consider the separation of concerns design principle to decouple the logging from other concerns, like transformation, in a single script. For example, avoid logging the message body in a script step that transforms the message, use the logging in a dedicated flow step instead.
* A prerequisite to use the message tracing is to set the message processing log level to TRACE. Details in
Enabling Trace for Message Processing.
The next contribution in this series is
How to Avoid Excessive Storage Load Caused by Using MPL Attachments for Message Logging
[Update 02.02.2018]
Changed reference how to enable tracing for message processing
[Update 12.02.2018]
Added reference to the next blog of the series.
