Announcement

Collapse
No announcement yet.

Mirth 1.5 - LLP channel problem

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Mirth 1.5 - LLP channel problem

    Environment: Mirth 1.5 Windows version, Windows Server 2000 SP4, Java Runtime v1.6.0 (build 1.6.0_01-b06)
    LLP to File Writer Channel w/ send ACK set to Yes
    Host: GE Centricity Practice Manager 2004 / Millbrook Integration Kit (MIK)
    IMPORTANT NOTE: The "LLP to File Writer" works fine with Mirth 1.4. Same channel with same set of messages from HL7 host does not work with Mirth 1.5

    Test Case 1: Imported 1.4 "LLP to File Writer" channel. Sent 143 A04 messages from HL7 host. Mirth 1.5 received just 1
    message. mirth.log is filled with this error:
    Message violates the minimal lower layer protocol: no start of message indicator received java.io.IOException: Message violates the minimal lower layer protocol: no start of message indicator received

    Test Case 2: Unchecked "Strip namespace from messages".
    Why? Comapred with Mirth 1.4. Looks like this option is new to 1.5 and was checked by default after the 1.4 channel was imported.

    Unchecked and tried sending the same set of 143 A04 messages. After a long delay Mirth 1.5 started receiving message. It

    received and ACKed 22 messages and a while later it became 27. Did not receive any message after that.

    mirth.log, mirth.log.1, mirth.log.2 has the following errors repeated.

    Message violates the minimal lower layer protocol: no start of message indicator received java.io.IOException: Message violates the minimal lower layer protocol: no start of message indicator received.

    Comments:
    I don't think this error message is valid because the same set of messages were received and ACKed successfully by Mirth 1.4
    File Attachment:

    Attached zip file has
    1. Channel export file (LLP to File Writer.xml)
    2. Microsoft Word document with Summary/Source/Destinations screen shot (Mirth 1.5 - LLP to File Writer Channel - Screen Shots.doc)

    Detailed Error Message:

    ERROR 2007-06-04 11:58:50,016 [dadde416-2c89-46c3-bee3-626a9098c922_source_connector._mllpEndpoint#-1173587322.receiver.10]

    org.mule.impl.DefaultComponentExceptionStrategy: Caught exception in Exception Strategy for:

    dadde416-2c89-46c3-bee3-626a9098c922: java.io.IOException: Message violates the minimal lower layer protocol: no start of

    message indicator received java.io.IOException: Message violates the minimal lower layer protocol: no start of message indicator received
    at com.webreach.mirth.server.mule.providers.mllp.prot ocols.LlpProtocol.readLLP(LlpProtocol.java:145)
    at com.webreach.mirth.server.mule.providers.mllp.prot ocols.LlpProtocol.read(LlpProtocol.java:191)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageReceiver$TcpWorker.run(MllpMessageReceiver. java:270)
    at org.mule.impl.work.WorkerContext.run(WorkerContext .java:290)
    at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.runTask(ThreadPoolExecutor. java:650)
    at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.run(ThreadPoolExecutor.java :675)
    at java.lang.Thread.run(Unknown Source)
    ERROR 2007-06-04 11:58:55,444 [dadde416-2c89-46c3-bee3-626a9098c922_source_connector._mllpEndpoint#-1173587322.receiver.10]

    com.webreach.mirth.server.mule.providers.mllp.prot ocols.LlpProtocol: Bytes received violate the MLLP: no start of message indicator received.

    followed by the HL7 message that caused this error. Mirth1-af05c47c6bde0454130108bd502862e1.zip (158997 bytes)
    Tags: None
  • #2
    Re:Mirth 1.5 - LLP channel problem

    On the LLP listener:
    1. Turn off "Use Strict LLP Validation"

    If you are still having issues, try turning off "Wait for End of Message Character"
    Chris Lang

    Comment

    • #3
      Re:Mirth 1.5 - LLP channel problem

      I don't recommend turning off Wait for End of Message Character unless your channel worked flawlessly in 1.4. It's possible to split messages if that option is turned off. Try what Chris suggested and it should work.
      Brendan Haverlock | Mirth Software Engineer | Mirth Corporation

      Comment

      • #4
        Re:Mirth 1.5 - LLP channel problem

        Centricity doesn't really send valid LLP. From what I remember, it doesn't include the wrapper characters by default, however MIK can be configured to use whatever ASCII codes as wrappers.
        Chris Lang

        Comment

        • #5
          Re:Mirth 1.5 - LLP channel problem

          Updated Note:

          Wait for End of Message Char - No

          I'll try with this setting set to Yes and post an update.

          Thanks!
          ----------------

          Thank you both for the reply.

          Started receiving the messages after following changes to the channel:
          Strip namespace from messages - Checked
          Use Strict LLP Validation - No

          Problems:

          1. Initial set of messages (about 3 to 5) are not getting immediately ACKed.
          This causes the host to retry and they eventually get ACKed by Mirth. This also results in getting extra message files in the destination. Sent 143, but Mirth shows 144 for Received and Sent and there are 144 message files in the Destinations folder.

          2. When Mirth Service is stopped, mirt.log file has the following error:

          ERROR 2007-06-04 16:10:33,756 [dadde416-2c89-46c3-bee3-626a9098c922_source_connector._mllpEndpoint#159008 2036.receiver.2] org.mule.impl.DefaultComponentExceptionStrategy: Caught exception in Exception Strategy for: dadde416-2c89-46c3-bee3-626a9098c922: java.lang.InterruptedException: sleep interrupted
          java.lang.InterruptedException: sleep interrupted
          at java.lang.Thread.sleep(Native Method)
          at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageReceiver$TcpWorker.run(MllpMessageReceiver. java:278)
          at org.mule.impl.work.WorkerContext.run(WorkerContext .java:290)
          at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.runTask(ThreadPoolExecutor. java:650)
          at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.run(ThreadPoolExecutor.java :675)
          at java.lang.Thread.run(Unknown Source)
          WARN 2007-06-04 16:10:40,186 [DatabasePruner] com.webreach.mirth.server.util.DatabasePruner: could not prune database
          com.webreach.mirth.server.controllers.ControllerEx ception: com.ibatis.common.jdbc.exception.NestedSQLExceptio n:
          --- The error occurred while applying a parameter map.
          --- Check the getChannel-InlineParameterMap.
          --- Check the results (failed to retrieve results).
          --- Cause: java.lang.NullPointerException
          Caused by: java.lang.NullPointerException
          at com.webreach.mirth.server.controllers.ChannelContr oller.getChannel(ChannelController.java:105)
          at com.webreach.mirth.server.util.DatabasePruner.prun eDatabase(DatabasePruner.java:66)
          at com.webreach.mirth.server.util.DatabasePruner.run( DatabasePruner.java:52)
          Caused by: com.ibatis.common.jdbc.exception.NestedSQLExceptio n:
          --- The error occurred while applying a parameter map.
          --- Check the getChannel-InlineParameterMap.
          --- Check the results (failed to retrieve results).
          --- Cause: java.lang.NullPointerException
          Caused by: java.lang.NullPointerException
          at com.ibatis.sqlmap.engine.mapping.statement.General Statement.executeQueryWithCallback(GeneralStatemen t.java:188)
          at com.ibatis.sqlmap.engine.mapping.statement.General Statement.executeQueryForList(GeneralStatement.jav a:123)
          at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.queryForList(SqlMapExecutorDelegate.java:615)
          at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.queryForList(SqlMapExecutorDelegate.java:589)
          at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.qu eryForList(SqlMapSessionImpl.java:118)
          at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.que ryForList(SqlMapClientImpl.java:95)
          at com.webreach.mirth.server.controllers.ChannelContr oller.getChannel(ChannelController.java:103)
          ... 2 more
          Caused by: java.lang.NullPointerException
          at java.io.DeleteOnExitHook.add(Unknown Source)
          at java.io.File.deleteOnExit(Unknown Source)
          at net.sourceforge.jtds.util.BlobBuffer.createBlobFil e(BlobBuffer.java:160)
          at net.sourceforge.jtds.util.BlobBuffer.setBinaryStre am(BlobBuffer.java:1037)
          at net.sourceforge.jtds.jdbc.TdsData.readData(TdsData .java:788)
          at net.sourceforge.jtds.jdbc.TdsCore.tdsRowToken(TdsC ore.java:2968)
          at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCor e.java:2236)
          at net.sourceforge.jtds.jdbc.TdsCore.getNextRow(TdsCo re.java:761)
          at net.sourceforge.jtds.jdbc.JtdsResultSet.next(JtdsR esultSet.java:593)
          at com.ibatis.sqlmap.engine.execution.SqlExecutor.han dleResults(SqlExecutor.java:380)
          at com.ibatis.sqlmap.engine.execution.SqlExecutor.han dleMultipleResults(SqlExecutor.java:301)
          at com.ibatis.sqlmap.engine.execution.SqlExecutor.exe cuteQuery(SqlExecutor.java:190)
          at com.ibatis.sqlmap.engine.mapping.statement.General Statement.sqlExecuteQuery(GeneralStatement.java:20 5)
          at com.ibatis.sqlmap.engine.mapping.statement.General Statement.executeQueryWithCallback(GeneralStatemen t.java:173)
          ... 8 more

          Post edited by: nshaik, at: 06/04/2007 13:40

          Comment

          • #6
            Re:Mirth 1.5 - LLP channel problem

            Turn off synchronization, and ensure "keep connection open" is set to true. Make your timeout value very large (several million milliseconds). (Sorry if you already have that set in your original channel, I can not download it here)
            Chris Lang

            Comment

            • #7
              Re:Mirth 1.5 - LLP channel problem

              With "Wait for End of Message Char" set to Yes, Mirth did not receive all messages. Received only 140. MIK (host HL7)log shows the first 4 messages caused "Connection refused" error.

              Comment

              • #8
                Re:Mirth 1.5 - LLP channel problem

                With "Wait for End of Message Char" set to Yes, Mirth did not receive all messages. Received only 140. MIK (host HL7)log shows the first 4 messages caused "Connection refused" error.

                Comment

                • #9
                  Re:Mirth 1.5 - LLP channel problem

                  Received all messages sent by the host. While monitoring MIK log, observed that some messages were not getting immediately ACKed but eventually all were sent successfully by the host MIK. Mirth Admin shows 143 Received and Sent as expected.

                  The settings were:

                  Summary Tab: Strip namespace from messages [Checked]
                  Source Tab:
                  Receive Timeout (ms): 5000000
                  Keep Connection Open: Yes
                  Use Strict LLP Validation: No
                  Wait for End of Message Char: Yes

                  When Mirth Service is stopped, it throws the following exception:

                  org.mule.impl.DefaultComponentExceptionStrategy: Caught exception in Exception Strategy for: dadde416-2c89-46c3-bee3-626a9098c922: java.lang.InterruptedException: sleep interrupted
                  java.lang.InterruptedException: sleep interrupted.

                  Comment

                  • #10
                    Re:Mirth 1.5 - LLP channel problem

                    Don't mind that exception; it is harmless. It just means the thread that is constantly listening for incoming LLP connections was interrupted.
                    Brendan Haverlock | Mirth Software Engineer | Mirth Corporation

                    Comment

                    • #11
                      Re:Mirth 1.5 - LLP channel problem

                      Add that to the Jira - let's catch that and log it before it get passed up to the exception handler.
                      Chris Lang

                      Comment

                      • #12
                        Re:Mirth 1.5 - LLP channel problem

                        Any clues on getting message from Mirth back into Centricity? :-)
                        Chris Lang

                        Comment

                        • #13
                          Re:Mirth 1.5 - LLP channel problem

                          Chris,

                          I'll send you an email on sending messages back to Centricity from Mirth.

                          Do you know why with Mirth 1.4 the ACK back to Centricity works fine but with 1.5 there's a delay for few messages?

                          Thanks!

                          Comment

                          Previous template Next
                          Working...
                          X
                          😀
                          🥰
                          🤢
                          😎
                          😡
                          👍
                          👎

                          We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.

                          By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.

                          I Agree