MessageProcessingMaxBodySize - System Parameter
The MessageProcessingMaxBodySize System Parameter sets the largest message body, in MB, that the Logging Service processes. A larger body is not processed, so one very large message can't exhaust the memory of the Logging Service. For BizTalk Server, a larger body is not even copied into Nodinite; the Log Event and its context are.
At a Glance
| Property | Value |
|---|---|
| Key | MessageProcessingMaxBodySize |
| Data type | integer (MB) |
| Default | 250 |
| Read by | Logging Service (message processing, and the copy of BizTalk tracked data), Web Client |
| Takes effect | Message processing: within about 5 minutes. BizTalk copy: the next copy run. No restart needed. |
| Status | ✅ Active |
| Since | Nodinite 5.0.0.29 |
How It Works
What happens to a message body above the limit depends on how it reaches Nodinite:
| Body logged with the Log API or another Log Agent | Body tracked by BizTalk Server | |
|---|---|---|
| Body over the limit is | Stored, not processed | Not copied; the Log Event and its context are |
| Processing state | Error | Completed with warnings |
| Search Field values | None | From the context only |
| Comment | …set to failed since body size was bigger than the threshold of X MB | …was not copied from BizTalk since it is larger than the threshold of X MB… |
| Log Audit level | Error | Warning |
How MessageProcessingMaxBodySize treats a body above the limit, by source.
Log API and Other Log Agents
When the Logging Service processes a Log Event whose message body is larger than MessageProcessingMaxBodySize, it skips the processing of that message (for example, no Search Field values are extracted) and instead:
- Sets the processing state of the Log Event to Error.
- Adds a Comment to the Log Event that explains why.
- Writes an entry with level Error to the Log Audit, which you can find with Log Audit Search.
The body is still stored. All other messages keep being processed. Message processing in general is described in the Logging Service Performance section.
Processing State in a Log View
In a Log View, the message that exceeded the limit shows the Error processing state.
The topmost Log Event exceeded the MessageProcessingMaxBodySize limit and got the Error processing state.
Comment on the Log Event
The Logging Service adds a Comment to the Log Event, visible in the Log View.
The Comment tells users why the message was not processed.
Log Audit Entry
The Logging Service also writes a Log Audit entry for traceability.
Search for these entries with Log Audit Search to find every message that was skipped because of its size.
BizTalk Server: The Body Is Not Copied, the Log Event and Its Context Are
When the BizTalk Log Agent copies tracked data from the BizTalk tracking database (BizTalkDTADb), a message body larger than MessageProcessingMaxBodySize is not copied to Nodinite. The Log Event and its context are copied, and the Logging Service processes the event from its context. Search Fields that read the context work; Search Fields that read the body find nothing. The Logging Service then:
- Sets the processing state to Completed with warnings, not Error: everything that was copied has been processed.
- Adds a Comment to the Log Event:
[Logging Service] The body (N MB) was not copied from BizTalk since it is larger than the threshold of X MB (System Parameter MessageProcessingMaxBodySize), the event was processed from its context only - Writes a Log Audit entry with level Warning that you can find with Log Audit Search:
The body was not copied from BizTalk since it is larger than the threshold of X MB, the event was processed from its context, …EventId=…, MessageGUID=…, TotalSize=…
The copy run also records it in its own Log Audit trail:
N context row(s) without body: the body is larger than X MB (MessageProcessingMaxBodySize) or BizTalk tracked no body, only the context is copied
The body size that BizTalk tracked is kept on the Log Event, so a Log View still shows the size even though the body is missing.
- The size is measured per message body, including all BizTalk fragments. BizTalk stores large messages in fragments.
- A changed value applies on the next copy run, without caching. A value that is not a positive integer makes the copy use
250MB.
Important
The body stays in the BizTalk tracking database only until BizTalk's own purge job removes it. Nodinite does not fetch it later if you raise the limit; as far as Nodinite is concerned, the Log Event is complete. See also how the BizTalk Log Agent recovers late tracked data.
Message Type Warning in the Web Client
New 7.11
The Web Client compares the Max Recent Body Size of each Message Type with MessageProcessingMaxBodySize. When a Message Type's recent messages are larger than the limit, a red warning badge appears in the Message Type list, the statistics panel, and the Repository panel. Use the badge to find the message flows that hit the limit.
Choosing a Value
- ✅ Keep the default
250MB unless you need even larger messages to be processed. - Before you raise the limit, make sure the Logging Service server has enough RAM: MessageProcessingBatchSize × the largest message body is roughly what the Logging Service may hold in memory at once. Test higher values before you use them in production.
- Lowering the limit gives more protection, but messages above it are no longer searchable by their body-based Search Fields.
- For BizTalk Server, lowering the limit means that bodies above it are never stored in Nodinite, not just unsearchable. Raising the limit later does not recover them.
- Check the Message Type warning badge before you change the limit, to see which message flows are affected.