Announcement

Collapse
No announcement yet.

Queing of request

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

  • Queing of request

    How does Mirth handle queing of request that are sent and recieved?

    If there is an error with the request does it try again?

  • #2
    Re: Queing of request

    bobbie,

    If I understand you correctly, I think you are referring to the way Mirth handles messages. Mirth handles messages via a queue. Incoming messages are received by the server where they are stored in a queue to be processed. The status of that message will be set to RECEIVED. When the server is not currently processing a message and there are messages in the queue, it removes the first message in the queue and begins to process it. Once it finishes process the message and actually sends it, it sets the status of that message to SENT, and then, it then grabs the next one and repeats the process. If a message causes an error, the status of that message will be set to "ERROR." If you would like to reprocess that message, you can go to the message browser and press the resend message button for the message with the error. Did that answer your question?

    -Brendan
    Brendan Haverlock | Mirth Software Engineer | Mirth Corporation

    Comment


    • #3
      Re: Queing of request

      Can the queue get full? If yes, what happens when more messages come in?

      I tried "LLP to Database" broad-cast channel with Mirth v1.2 and wrote a query to make the HL7 host send 142 messages (ADT:A04).

      The HL7 host log shows all 142 messages were sent (took less than 2 minutes) but Mirth processed only 137 and 5 were "lost". This happens both in Mirth v1.1 and v1.2. In v1.1 I tried changing the buffer size but that did not help.

      Comment


      • #4
        Re: Queing of request

        Yes you answered my question.

        Thank you very much.

        When a message errors, does it say why it errored? Does mirth allow you to walk through the message and see where it errored?

        Thanks again...

        Comment


        • #5
          Re: Queing of request

          I have been testing 1.2 by sending it tens of thousands of messages, and I have not run into any problems with the queue becoming full. I'd imagine it depends on the size of the heap that you have allocated to Java. As far as I know, the message browser does tell you the error that occurred while processing the message. Also nshaik, what exactly do you mean by lost? If you filter the message browser by all errors, do the "lost" messages show up?
          Brendan Haverlock | Mirth Software Engineer | Mirth Corporation

          Comment


          • #6
            Re: Queing of request

            brendanh,

            Thank you very much for the quick reply.

            Mirth does not show any errors but the messages get "lost" / "missing". They are not received by Mirth (Received: 137, Sent: 137, Errors: 0).

            I tried with a third-party tool called TcpTrace which showed it did get 142 messages. This means the box where Mirth is running did receive all the messages sent by the host HL7.

            If I change the channel to "File Reader to Database" Mirth processes all the 142 messages successfully.

            How do I change the Java heap size?

            Thanks

            Comment


            • #7
              Re: Queing of request

              Nazir,

              What are you using to push the messages out to Mirth?

              You can change the Java heap size by adding:

              -Xmx###M to the JAVA command line arguments in Mirth.bat (or .sh) (where ### indicate the number of megabytes to use).

              When handling large batches of messages, we usually set the heap to 512:

              -Xmx512M

              -Chris
              Chris Lang

              Comment


              • #8
                Re: Queing of request

                There are two ways to make the HL7 host (Centricity Practice Manager 2004) send HL7 messages out:

                1. Use the client application to update patient info, schedule appointment etc. When the client application updates the database, the host server application recognizes database changes, populates a table called MIKEventLog with the appropriate message type and id.


                2. The other way is to populate the backend database table directly with a query like
                ===============
                INSERT MIKEventLog(Data, Type, Status, RetryCount, Destination, TimeStamp)
                SELECT PatientProfileId, 'HL7 2.3^ADT^A04', 0, 0, 'MirthHl7Test', GetDate()
                FROM PatientProfile

                This would populate one record for each patient.
                ===============

                The HL7 host service would send a message for each entry and delete the record from MIKEvent table after sending the message successfully.

                In the e.g. above, it would send A04 message for each patient in the database.

                I use the second method to push the messages out to Mirth.

                And that's what we typically do when we do a new installation. We do not write database scripts to migrate patient, appointment, referring doctor records. We setup our HL7 and populate the MIKEventLog table with appropriate queries and let it populate our database tables.

                Comment


                • #9
                  Re: Queing of request

                  Very interesting - good to know. Is there any way to push those messages out to a file or some other receiver that can dump to a file? Maybe there were issues with certain messages that came in that caused Mirth to reject them at the LLP level.

                  -Chris
                  Chris Lang

                  Comment


                  • #10
                    Re: Queing of request

                    The HL7 host gives an option to send the messages as files as well. I tried that and both Mirth v1.1 and v1.2 process all 142 files sent by the host. The "missing / lost" message problem happens only when the channel is setup as "LLP to Database".

                    Comment


                    • #11
                      Re: Queing of request

                      AS far as I know, there is not a such "queue" in MIRTH.

                      When a new LLP connection is detected, a thread is lauch. This thread process the message. Each thread set the different state of the message from "ACCEPTED", "TRANSFORMED", "SET" or "ERROR". There is no way of changing the number of max threads.

                      I've tested Mirth with more than 2000 messages incoming in a low-capacity server without any problem. ┬┐Have you checked the 'System log'? every exception accepting a LLP message is logged here.

                      Comment


                      • #12
                        Re: Queing of request

                        albertosaez,

                        Thank you for the feedback. Looks like the problem could be related to messages being sent very fast (2 messages / second). I checked the following post in Developers forum:
                        ======================

                        Mirth stops responding to LLP messages

                        http://www.mirthproject.org/index.ph...=148&Itemid=63
                        ======================

                        Hopefully the problem would be fixed in 1.2.2.

                        Thanks

                        Comment

                        Working...
                        X