Announcement

Collapse
No announcement yet.

Mirth 3.2 - Connection / ACK issues

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

  • Mirth 3.2 - Connection / ACK issues

    OS - Linux version 2.6.23.17-88.fc7 ([email protected])
    Java - 1.7.0_75
    Mirth Connect - 3.2
    Database - psql (PostgreSQL) 8.3.11

    Channel Source is setup as:
    TCP Listener
    All interfaces
    Port: 6677 (tried other ports same issue)
    Source Queue - On
    Response - Auto-generate
    Transmission - MMLP
    Frame - <VT>{message}<FS><CR>
    Mode - Server

    Recently upgraded one of our servers from 2.1.1 to 3.2.Been having some very odd issues with TCP Listeners / MMLP. When I deploy channels I'm able to telnet to the ip/port (on a different PC). However Mirth does not show any connections and running - "lsof -n | grep {port}" shows as Listening, but nothing connected. Rebooting the entire server sometimes gets the channels working however once I do a redeploy it instantly breaks. I ended up having to revert back to Mirth 2.1.1 using java 1.6 and works fine.

    I also ran - "tcpdump -nn port {port}" then connected via telnet and it shows the connection happening. Again, Mirth shows no connection nor does running "lsof".

    When actually trying to send an hl7 message to that channel, from another mirth server, the sending mirth gets timeout waiting for ack, nothing ever received.

    I'm so confused what could be happening......

  • #2
    Mcanalld,

    I upgraded from 2.2 without this kind of issues, do you have any kind of firewall activated?. Did you tried to connect from same server?, Did you checked your channel config?. Finally, could you maintain Mirth 2.1 version and just upgrade to java 1.7?. Some issues derived from this upgrade due to java security issues.

    HTH,

    Ricard Bernat

    Comment


    • #3
      All iptables (firewalls), IPV4 and IPV6 are disabled. I also disabled IPV6 on network card just because I've seen other odd issues, not Mirth related.

      I have not tried connecting locally to see what result is, but I will. Odd part is, I can connect it just doesn't think it's connected. I originally thought maybe an OS issue (Fedora 7 a bit out dated, and maybe still is) but why when 2.1.1 is installed it works fine? I have mirth 3.2 on other boxes an no issues at all. They are running CentOS 6.4 tho.

      Mirth 2.1.1 is not java 1.7 supported. I'd need to upgrade to 2.2, which may be possible. I also need to move from 2.1.1 to something higher because I have other 3.2 servers running which requite java 1.7 for client. And java 1.7 for 2.1.1 client doesn't work well (test connection is broken, and channel stats refresh breaks).

      Comment


      • #4
        Gets even better. If I set channel to deploy in "Stopped" state, then Start it, it works fine. If I deploy in "Started" state a good chance it won't work but if I stop channel then start it, works fine.

        Comment


        • #5
          Hi mcanalld,

          how many network interfaces got this server?. Did you found some solution about?.

          Ricard Bernat

          Comment


          • #6
            No, never got it to work properly. Just has a loopback interface and 1 nic using eth0. I've triple checked everything when it comes to network and don't see any issues. I'll be replacing the server early next week with with new hardware and newer OS.

            I'm still trying to fix it when I get bored. I have both mirth 2.1.1 and 3.2 running on same box right now. 2.1.1 has all the production channels. I also installed java 8 and have 3.2 using that but didn't fix issue.

            Comment


            • #7
              Does it only happen with the TCP Listener? What about with another source connector type like the HTTP Listener?
              Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

              Nicholas Rupley
              Work: 949-237-6069
              Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


              - How do I foo?
              - You just bar.

              Comment


              • #8
                TCP - Basic
                TCP - MLLP

                Are both affected. I assumed that'd be the case.


                I setup an HTTP listener that just replies back with all channel statistics in xml format and it works fine. That surprisingly worked, even with multiple channel redeployments which typically break tcp channels.

                Comment

                Working...
                X