Message Drop on MLLP mode of TCP/IP listener

[saro3392]

Hello All,

Mirth Version : 3.2.1

I am using MLLP mode of listener to receive the data from one of my PMS.
Channel receiving over 20,000 messages per day. But some times message exit from PMS, but didn't reached to mirth channel. The message drop level is 20% per day

Both mirth and PMS in separate servers, how ever both are in same internal network.

Is there any chance MIRTH could be the cause of message drop, since it was handling multiple requests ?.

Do i need to change anything in channel to avoid the message drop ?

Can anyone please help or suggest on this.

Thanks in Advance.

Source Connector configuration as follows:

Type : TCP Listener
Mode : MLLP
Max : 10
Receive Timeout : 0
Buffer Size : 65536
Keep Connection Open: Yes
Data Type: Text
Encoding : Default

[spycom]

Do you have the source queue turned on?

[saro3392]

Thanks for quick reply.
No, currently it set to OFF. Will that cause issue ?

[spycom]

Don't quote me on this, but I'd say that without the queue, if one message takes too long to process, the next message in line at the source might time out.
As a habit, I always turn it on because I don't care about the validity of the message (usually), I only care that I got it, so I send the ACK as soon as I get it and let things queue up to process.

[saro3392]

Okay. But i am not sending any ACK, that's why i turned off the queue. Thanks for pointing out the queue. I will check more on queuing the messages.

[spycom]

You can still tell it not to send an ACK

[saro3392]

Can anyone please explain how the source queue works?..
Will the message cleared from queue once its processed. I am not sending ACK back to origin.
And also please tell me the size limit of source queue.

[spycom]

Originally Posted by saro3392

Can anyone please explain how the source queue works?..
Will the message cleared from queue once its processed. I am not sending ACK back to origin.
And also please tell me the size limit of source queue.

To the best of my understanding, it works like this:
First message comes in and starts to process
Second message transmits, then sits in the source queue until the first message has completed processing, and then starts its own processing
Rinse and repeat

I've had queues thousands of messages deep during a backload into Mirth Results.

The source queue really makes a difference when you have slow destinations, or really heavy processing and you have a source that is constantly transmitting.

Go to your Source connector tab; Set the Source Queue to "ON" and set the response to "None" if you don't plan on sending an ACK.

[saro3392]

Thank you very much for clear explanation,
I will turn on the source queue and will test it my environment.
Once again, Thanks a lot.

[phatneff]

Ok, but what if the source is expecting an ACK before it sends the next message? This wouldn't help with a slow source connection and the Mirth source connection set to NOT keep the connection open. Does that sound right?