Announcement

Collapse
No announcement yet.

Error - Transaction IDs do not match

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error - Transaction IDs do not match

    I'm wondering if someone could help
    Were using Mirth Connect v 3.3.2.7911

    I have two destinations that are a TCP Sender that every now and then errors with the message "message control IDs do not match" but when I check the source and the sent message they are the same.

    However as soon as the message is re-sent it sends successfully without error. There is nothing similar between the messages that do and don't error. I cannot spot any pattern.

    This is only occurring to these two destinations that connect to the same client.

    Has anyone else experienced this or can anyone suggest a potential fix?

  • #2
    I have seen a similar error. A few different scenarios caused it: the response timeout was set to a higher ms than Interval ms on advanced queue settings. What would happen is sometimes a message would be resent before it received a timeout and the message ID's would not match on the ACK. Another scenario was similar, because we had the number of retires set on advanced queue settings.

    I would check to make sure the response timeout is correct, advanced queue settings is correct, one of the destinations is not holding the connection from the other, and possibly check with the vendor to make sure they are sending the correct ACK since the problem is only for this single destination.

    hope this helps some. just my two cents.

    Comment


    • #3
      both the response timeout and the send timeout are set at 5000
      in the advanced queue settings we have 0 retries and 5000ms. so I do not think it is a retry issue.

      other users have suggested taking the validate response option off - to stop this error
      BUT we have to pass the response onto the sending application. They will not send the next message until they have received a valid ACK for the last.

      We have spotted a few instances since where this error occurs and the message id's genuinely DO NOT MATCH.

      another suggestion was to set the "keep connection open" option to "off" but we tried this and it didn't make much difference.

      another option is not to validate on the message ID - but again, the sending app needs this back and the receiving app doesn't always send the responses with the matching message (or MIRTH is jumbling them up because we have filtered some of the messages out and some have errored).

      Any suggestions?

      Comment


      • #4
        Have you asked the vendor to verify they are sending back an ACK every time?

        Maybe it is an issue with the vendors ACK?

        Comment

        Working...
        X