Announcement

Collapse
No announcement yet.

Receiving mllp hl7 messages from multiple sources

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

  • Receiving mllp hl7 messages from multiple sources

    If I have one llp receive channel, can Mirth handle receiving messages from multiple sources? Is there a limit?

  • #2
    Re:Receiving mllp hl7 messages from multiple sourc

    What do you mean with "multiple sources"? many systems piping messages to the same Mirth channel?

    Comment


    • #3
      Re:Receiving mllp hl7 messages from multiple sourc

      quimicefa wrote:
      What do you mean with "multiple sources"? many systems piping messages to the same Mirth channel?
      That's what I mean. One mirth channel set up as LLP receive. Several 3rd party applications openning tcpip connections all to the same ip address and port, and sending HL7 messages to mirth.

      Comment


      • #4
        Re:Receiving mllp hl7 messages from multiple sourc

        I don't think there is a limit on how many source systems can send to one Mirth channel. At least I don't think you have to worry about it unless you have hundreds of systems sending to the same channel.
        Daniel Svanstedt
        Software Engineer
        Mirth Corporation

        Want professional services, support, and enterprise or virtual appliances? It's all available from the Mirth Corporation:
        Mirth Support | Mirth Training | Mirth Appliances | Online Training | Developer Q&A

        Don't forget, Mirth Support gives you access to all of our online training videos, and silver support gives you access to developer Q&As!

        Comment


        • #5
          Re:Receiving mllp hl7 messages from multiple sourc

          dans wrote:
          I don't think there is a limit on how many source systems can send to one Mirth channel. At least I don't think you have to worry about it unless you have hundreds of systems sending to the same channel.
          I ask because we've got a situation where we have around 30 outbound HL7 interfaces in our 3rd party application all sending to 1 inbound mirth channel. Each outbound interface opens it's own tcpip connection, and we're finding that periodically these outbound interfaces are crashing. The vendor is asking if there are limits to how many connections mirth can handle on a single channel. They're speculating that there are limits which are being reached due to the amount of outbound interfaces trying to make connections to mirth, and that a limit is being reached by mirth and the outbound interfaces aren't handling it gracefully. I still think the problem is on the 3rd party application side, but I do need to get the details about how mirth works in this scenario, so I can arm myself with an answer for the vendor.

          Comment


          • #6
            Re:Receiving mllp hl7 messages from multiple sourc

            Well, the first limit on the connections is related to the max files open, at least in unix environments. Check it with "ulimit -a", but this limit is related with the concurrent sockets that are handled by the interface.

            AFAIK, also the JVM can be tweaked to raise the max connections that can handle.

            I think that this is not a Mirth limitation, but an OS/tuning one depending on the configuration of the OS, hardware, network drivers ...

            Comment


            • #7
              Re:Receiving mllp hl7 messages from multiple sourc

              jerchap wrote:

              Each outbound interface opens it's own tcpip connection, and we're finding that periodically these outbound interfaces are crashing. The vendor is asking if there are limits to how many connections mirth can handle on a single channel.
              If "crashing" means what tech people usually mean when using that term, I'd be asking the vendor why their application has problems talking to that many connections. Seems to me like it's bad error handling on the sending application's part.

              Post edited by: mnowlin, at: 02/26/2009 23:29

              Comment


              • #8
                Re:Receiving mllp hl7 messages from multiple sourc

                mnowlin wrote:

                If "crashing" means what tech people usually mean when using that term, I'd be asking the vendor why their application has problems talking to that many connections. Seems to me like it's bad error handling on the sending application's part.<br><br>Post edited by: mnowlin, at: 02/26/2009 23:29[/quote]

                You're probably right, I just wanted some external opinions to validate what I thought was the real problem here. And I think you guys provided that. Thanks.

                Comment


                • #9
                  Really old thread, but if anybody has been in this situation and could post what they did to resolve it, I'd greatly appreciate it.

                  Comment


                  • #10
                    We didn't necessarily resolve the issue, but decided to go with multiple inbound channels, that all pushed the message to a common channel that had the common logic. I think this is best practice anyhow, as it lets you troubleshoot/see stats, etc for each incomming interface. I beleive that from a best practice perspective you should strive for a 1:1 relationship between sending systems and inbound channels, and a 1:1 relationship between outbound channels and receiving systems as well.

                    Comment


                    • #11
                      Agree with the above re best practice, but there's also another factor.

                      I recently wrote a PHP portal for some colleagues who wanted to be able to interrogate their database of inbound messages and resend based on certain criteria. I used the fsock functions in PHP and initially used a loop of open/send/close, however watching the Mirth dashboard you quickly saw the connected clients figure jump up and stick at 10, which caused the sender to fall over after a while (talking 10k+ msgs). I eventually changed the script to use open/send-loop/close to use a single TCP session because of this.

                      So for most systems it may not be a problem, but in a heavy traffic environment a channel per sending system is a good idea.

                      Comment


                      • #12
                        Thanks for replying with your work-arounds.

                        From a programming perspective I had been looking forward to keeping as few channels as possible for ease of deployment and version control. I think the root problem is the 3rd party apps we have to deal with not handling the absence of a timely ACK from Mirth well... but you have to work within the realm of what you can change.

                        Instead of routing messages from particular clients to a common base code, as we've been branching out to in recent months (instead of everything connecting directly to the base code), we'll instead duplicate the core functionality for each client. The reason being that all our messages need to be processed in order, and if one client decides to send us 100k messages out of the blue it can put all other clients on hold. If it was possible to process different clients asynchronously (via looking at the message sender) and still process messages from the same client in order then it'd be a different story.

                        Deploying changes is going to be horrible, but I don't see any other work around.

                        Regards,
                        -Scott

                        Comment

                        Working...
                        X