Announcement

Collapse
No announcement yet.

Mirth loses connection to its own SQL Server database

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

  • Mirth loses connection to its own SQL Server database

    Hello,
    I switched the default mirthdb from Derby to Azure SQL Server and all tables created as expected with no issue. The problem I am experiencing now is the first transaction that goes through a channel that has been sitting idle for a while, fails with the below error and goes into limbo until I restart the channel and sometimes the message is recovered. The transactions following the initial are fine and process without issue. I am not connecting to any database to store the data, just receiving HL7 and writing to the file system. Mirth seems to lose connectivity to its own database and I need a way to auto reconnect internally or fix this at a network level (which is not my forte). Any suggestions? Or is this error something totally unrelated to connecting to the mirthdb?

    Here is the error:
    [2016-12-27 20:47:46,485] ERROR (com.mirth.connect.donkey.server.channel.RecoveryT ask:218): Failed to recover message 21 for channel TEST_INBOUND_ORU_FILESYSTEM (0c800396-134a-4042-9f2c-a2989c2b1e0c):

    com.mirth.connect.donkey.server.data.DonkeyDaoExce ption: java.sql.SQLException: Invalid state, the Connection object is closed.
    at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. close(JdbcDao.java:2105)
    at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.executeTasks(BufferedDao.java:150)
    at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.commit(BufferedDao.java:85)
    at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.commit(BufferedDao.java:67)
    at com.mirth.connect.donkey.server.channel.Channel.pr ocess(Channel.java:1679)
    at com.mirth.connect.donkey.server.channel.RecoveryTa sk.doCall(RecoveryTask.java:166)
    at com.mirth.connect.donkey.server.channel.RecoveryTa sk.call(RecoveryTask.java:43)
    at com.mirth.connect.donkey.server.channel.RecoveryTa sk.call(RecoveryTask.java:29)
    at java.util.concurrent.FutureTask.run(FutureTask.jav a:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

    Caused by: java.sql.SQLException: Invalid state, the Connection object is closed.
    at net.sourceforge.jtds.jdbc.JtdsConnection.checkOpen (JtdsConnection.java:1744)
    at net.sourceforge.jtds.jdbc.JtdsConnection.getAutoCo mmit(JtdsConnection.java:2187)
    at com.zaxxer.hikari.proxy.ConnectionProxy.close(Conn ectionProxy.java:187)
    at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. close(JdbcDao.java:2102)
    ... 11 more

  • #2
    This problem could occur if your polling frequency is too less on your source reader around like 5-10 secs.
    HL7v2.7 Certified Control Specialist!

    Comment


    • #3
      Thank you for your quick response, siddarth! With this particular channel the Source is a TCP Listener (MLLP, Keep Connection Open is Yes and Receive Timeout is 0) doing minor HL7 mapping and writing to the local file system. I've tried it with setting Keep Connection Open to No and it still errors. It's also the only deployed channel

      Comment


      • #4
        I am thinking the problem may not actually reside on your channel but between mirth and azure hosted db. As you said, only the first time you face this error, then it could be it is trying to open the db connection to write the record, where it could be facing some level of latency.
        It could be a potential reason.
        HL7v2.7 Certified Control Specialist!

        Comment


        • #5
          Has this issue been resolved? We experience the same behavior when attempting to use Azure to store the mirth databases. It seems the connection closes after the first transaction and cannot be reopened. Attempts to fix it using the connection flags (keepAlive, socketTimeout, etc) have no impact.

          Comment


          • #6
            Connection to MirthDB in Azure

            I am running Mirth 3.5.2 on a VM within Azure. The Mirth database is on a SQL Server managed instance within the same Azure subscription. I have several channels which consume ADT/ORM messages which seem to be working as expected, however, I also have a File Reader channel which reads PDF files from disk and sends them as MDM messages. This channel is intermittently erroring (see stack trace below) in what appears to me to be with its connection to the Mirth DB. I am assuming that this is due to the fact that it is attempting to save out the larger file data as it moves through the steps in the channel since the ADT/ORM channels are not having the same issue. Does anyone have any thoughts on how to resolve this issue?

            Also, I have alerts configured to send email when an error occurs. I am recieving these when the error is within the channel, but I am not being notified of these internal Mirth errors. Is there any way that I can be notified?

            Mike

            com.mirth.connect.donkey.server.channel.ChannelExc eption: com.mirth.connect.donkey.server.data.DonkeyDaoExce ption: java.sql.SQLException: I/O Error: Connection reset
            at com.mirth.connect.donkey.server.channel.Channel.di spatchRawMessage(Channel.java:1213)
            at com.mirth.connect.donkey.server.channel.SourceConn ector.dispatchRawMessage(SourceConnector.java:192)
            at com.mirth.connect.donkey.server.channel.SourceConn ector.dispatchRawMessage(SourceConnector.java:170)
            at com.mirth.connect.connectors.file.FileReceiver.pro cessFile(FileReceiver.java:354)
            at com.mirth.connect.connectors.file.FileReceiver.pro cessFiles(FileReceiver.java:247)
            at com.mirth.connect.connectors.file.FileReceiver.pol l(FileReceiver.java:203)
            at com.mirth.connect.donkey.server.channel.PollConnec torJob.execute(PollConnectorJob.java:49)
            at org.quartz.core.JobRunShell.run(JobRunShell.java:2 13)
            at org.quartz.simpl.SimpleThreadPool$WorkerThread.run (SimpleThreadPool.java:557)Caused by: com.mirth.connect.donkey.server.data.DonkeyDaoExce ption: java.sql.SQLException: I/O Error: Connection reset
            at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. insertContent(JdbcDao.java:274)
            at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. insertMessageContent(JdbcDao.java:193)
            at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.executeTasks(BufferedDao.java:110)
            at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.commit(BufferedDao.java:85)
            at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.commit(BufferedDao.java:72)
            at com.mirth.connect.donkey.server.channel.Channel.di spatchRawMessage(Channel.java:1185)
            ... 8 moreCaused by: java.sql.SQLException: I/O Error: Connection reset
            at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCo re.java:1093)
            at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL (JtdsStatement.java:563)
            at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.ex ecuteUpdate(JtdsPreparedStatement.java:727)
            at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. insertContent(JdbcDao.java:271)
            ... 13 moreCaused by: java.net.SocketException: Connection reset
            at java.net.SocketInputStream.read(Unknown Source)
            at java.net.SocketInputStream.read(Unknown Source)
            at java.io.DataInputStream.readFully(Unknown Source)
            at java.io.DataInputStream.readFully(Unknown Source)
            at net.sourceforge.jtds.jdbc.SharedSocket.readPacket( SharedSocket.java:850)
            at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacke t(SharedSocket.java:731)
            at net.sourceforge.jtds.jdbc.ResponseStream.getPacket (ResponseStream.java:477)
            at net.sourceforge.jtds.jdbc.ResponseStream.read(Resp onseStream.java:114)
            at net.sourceforge.jtds.jdbc.ResponseStream.peek(Resp onseStream.java:99)
            at net.sourceforge.jtds.jdbc.TdsCore.wait(TdsCore.jav a:4127)
            at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCo re.java:1086)
            ... 16 more

            Comment

            Working...
            X