Skip to Content

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.

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 DEBUG as described in the blog Setting the Log Level for Message Processing.

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply