Time Delay from One channel(attachment-reattachemnt) To another Channel Document Processing)

[DuaNazakat]

Hi everyone,

I’m currently using Mirth Connect 4.5.2 with a MySQL database, and have run into an intermittent issue I hope the community can help me debug.

Setup
We have an HL7 processing pipeline involving attachments (PDF, XML, and text) with the following channels:

🔹 Source-oru-R01-channel (Channel A)

1. Receives inbound HL7 messages from a client Mirth instance.
2. Performs basic validations on required HL7 fields.
3. Store Attachments and pass to the next channel

🔹Save-inbound channel (bridge channel)
Channel Settings: Production mode Message Pruning:15 days

1. Saves the inbound message (log into Db).
2. Extracts OBX segments with ${ATTACH:channelId:messageId:attachmentId} placeholders.
3. Performs reattachment logic via custom JavaScript (calling getAttachment(...) with retries 3 and delay 10000ms).
4. Queues the message for downstream processing.

🔹 Document-processing-channel (Channel B)

1. Receives the message from the source channel.
2. Performs heavy processing (document generation, report handling, DB writes, etc.)
3. Expected to work on OBX segments that already contain full base64 content or text, restored from attachments.

❌ The Problem

We’ve confirmed:
Attachments are properly created and saved in the database.
The reattachAttachments() logic is running with retries (3 attempts, 10000ms delay).
No warnings or errors are logged when this failure happens.
The message gets queued (we have thread count = 4).
Timing logs show a large time gap between the inbound message and the document processing phase, but no failure trace.

🔍 What We’ve Tried So Far

1. Added detailed logging for getAttachment(...), which shows successful fetches most of the time.
2. Indexed the D_MA1 attachment table (MESSAGE_ID, ID) to speed up lookups.
3. Reduced retries/delay to 2x @ 500ms to avoid blocking threads.
4. Message Setting to Raw mode
5. Message Storage to 7 days earlier it was 15 days

🧠 Suspected Causes
We suspect the issue might stem from:
The incoming stream is much higher than the downstream that causes the message in the queue for the long time

❓ Looking for Help
Has anyone seen similar intermittent reattachment failures in Mirth 4.x when using attachments?

Thanks in advance!