Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

Queued/Retry status of an MLLP message

  • Filter
  • Time
  • Show
Clear All
new posts

  • Queued/Retry status of an MLLP message

    I have a channel with an LLP destination. The Max retry count is 99. The destination application is currently down, which provides me with a good testing oportunity. As expected, the dashboard shows an error for this channel. Double clicking on the channel shows a log with two lines, one for the source connector, which has a status of TRANSFORMED, and one for the destination connector which has a status of ERROR.

    1) How do I know the retry/queue status of the errored message? IE: when it will be next retried, what retry interval it is currently on (3 of 99, etc), or if it's going to be retried at all?

    2) How do I tell if the max retry count has been exceeded, in which case I will need to manually reprocess the message?

    3) Is there any way to set the retry count more than 99? We have a destination application which has gone down for days in the past. With thousands of messages going through mirth each day, we don't want to have to do manuall intervention.

    channel properties

    <name>To GoldCare</name>
    <property name="usePersistentQueues">0</property>
    <property name="replyChannelId">074ce053-91cc-4518-8aa5-ec7f844dcdfd</property>
    <property name="ackTimeout">420000</property>
    <property name="sendTimeout">5000</property>
    <property name="maxRetryCount">99</property>
    <property name="host"></property>
    <property name="tcpProtocolClassName">org.mule.providers.tcp .protocols.TcpProtocol</property>
    <property name="port">15600</property>
    <property name="recordSeparator">0x0D</property>
    <property name="template">${message.transformedData}</property>
    <property name="hl7AckResponse">1</property>
    <property name="DataType">LLP Sender</property>
    <property name="messageStart">0x0B</property>
    <property name="reconnectMillisecs">10000</property>
    <property name="charsetEncoding">DEFAULT_ENCODING</property>
    <property name="segmentEnd">0x0D</property>
    <property name="charEncoding">hex</property>
    <property name="messageEnd">0x1C</property>
    <property name="channelName">HL7 Archive</property>
    <property name="keepSendSocketOpen">0</property>
    <property name="bufferSize">65536</property>
    <transportName>LLP Sender</transportName>
    <property name="synchronous">true</property>
    <property name="removeNamespace">true</property>
    <property name="encryptData">false</property>
    <property name="store_messages">true</property>
    <property name="dont_store_filtered">false</property>
    <property name="initialState">started</property>
    <property name="max_message_age">30</property>
    <property name="transactional">false</property>
    <property name="error_messages_only">false</property>

  • #2
    Re:Queued/Retry status of an MLLP message

    For MLLP you could activate queues to ensure no message is lost.