Announcement

Collapse
No announcement yet.

HTTP Sender Connector - MC 3.5.1 vs MC 3.6.2

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

  • HTTP Sender Connector - MC 3.5.1 vs MC 3.6.2

    We have a channel on MC 3.5.1 that contains two HTTP Sender destination connectors. The first one is a POST to get an login authorization token from the destination and the second one is another POST that sends the HL7 message to the destination. This works great. The receiving system gets the messages and sends an ACK back to Mirth.

    We have also installed MC 3.6.2 on the same server but with a separate service to run the 3.6.2 instance. The channel mentioned above was imported and has all of the same settings as the 3.5.1 version. However, when the message reaches the destination connector, it queues in both of the HTTP Sender destinations with this error for each:

    HTTP Sender error
    ERROR MESSAGE: Error connecting to HTTP server
    java.lang.ClassCastException


    The Response Status is:

    QUEUED: Error connecting to HTTP server [ClassCastException: null]

    If the settings in both 3.5.1 and 3.6.2 are identical for the channel and connectors, what could possibly be the issue as to why a connection can't be established and messages can't be sent?

    P.S. Only the corresponding MC service is running for whichever MC version we are using to test. We don't have both services running concurrently.

    Let me know if you need anything else to help resolve this problem.

  • #2
    Another Response Status message:

    QUEUED: Error connecting to HTTP server [ClassCastException: [B cannot be cast to java.lang.String]

    Comment


    • #3
      That second one looks like you are passing a byte[] somewhere where it's expecting a String.

      Maybe using a velocity variable for hostname or template or something?

      Comment


      • #4
        Nothing has changed from the 3.5.1 channel to the 3.6.2 channel as far as our development. I'm assuming it's some coding in MC that i can't access to resolve?

        Comment


        • #5
          Ok, now I'm seeing this, too:

          ERROR (com.mirth.connect.connectors.http.HttpDispatcher: 746): Error processing queued message 119-3 (QUEUED) for channel Procura_ADT_Outbound (c32855df-cdf7-4c21-85e5-7cd5cff7a01a) on destination _get_auth. This error is expected if the message was manually removed from the queue.
          com.mirth.connect.donkey.server.data.DonkeyDaoExce ption: org.postgresql.util.PSQLException: ERROR: insert or update on table "d_mc27" violates foreign key constraint "d_mc27_fkey" Detail: Key (message_id, metadata_id)=(119, 3) is not present in table "d_mm27".
          at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. storeContent(JdbcDao.java:336)
          at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. storeMessageContent(JdbcDao.java:264)
          at com.mirth.connect.plugins.clustering.server.FenceD ao.storeMessageContent(FenceDao.java:89)
          at com.mirth.connect.donkey.server.data.buffered.Buff eredDao.executeTasks(BufferedDao.java:117)
          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.plugins.clustering.server.FenceD ao.commit(FenceDao.java:371)
          at com.mirth.connect.donkey.server.channel.Destinatio nConnector.run(DestinationConnector.java:730)
          at java.lang.Thread.run(Unknown Source)Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on table "d_mc27" violates foreign key constraint "d_mc27_fkey" Detail: Key (message_id, metadata_id)=(119, 3) is not present in table "d_mm27".
          at org.postgresql.core.v3.QueryExecutorImpl.receiveEr rorResponse(QueryExecutorImpl.java:2455)
          at org.postgresql.core.v3.QueryExecutorImpl.processRe sults(QueryExecutorImpl.java:2155)
          at org.postgresql.core.v3.QueryExecutorImpl.execute(Q ueryExecutorImpl.java:288)
          at org.postgresql.jdbc.PgStatement.executeInternal(Pg Statement.java:430)
          at org.postgresql.jdbc.PgStatement.execute(PgStatemen t.java:356)
          at org.postgresql.jdbc.PgPreparedStatement.executeWit hFlags(PgPreparedStatement.java:168)
          at org.postgresql.jdbc.PgPreparedStatement.executeUpd ate(PgPreparedStatement.java:135)
          at com.mirth.connect.donkey.server.data.jdbc.JdbcDao. storeContent(JdbcDao.java:332)
          ... 8 more


          There aren't tables "d_mc27" and "d_mm27" in the 3.6.2 postgresql db but they are in the 3.5.1 postgresql db. So how does this get resolved?

          Comment


          • #6
            Maybe try to clone the channel and use the clone? That should create all of the needed tables. Not sure why they wouldn't be there in the first place.

            Comment


            • #7
              Cloned it and got the same errors.

              Comment


              • #8
                Which errors? The first or last? Are you still missing tables?

                Are you able to post your channel?

                Comment


                • #9
                  Yes, both errors I've posted.

                  I don't think I can post the channel as it has connection information in it to an external customer.

                  Comment


                  • #10
                    It shouldn't still be trying to use the same tables with a cloned channel. It should have assigned a new id to the new channel.

                    Comment


                    • #11
                      The table error message only appears when the service starts up and it shows up in the Server Log. So let's ignore that error for now. The cloned channel still gets this error just like the regular channel:

                      HTTP Sender error
                      ERROR MESSAGE: Error connecting to HTTP server
                      java.lang.ClassCastException

                      The Response Status is:

                      QUEUED: Error connecting to HTTP server [ClassCastException: null]

                      Comment


                      • #12
                        This is what was seen when trying to trace the connection:

                        We used a netstat command to see TCP connections from Mirth server from LBMIRTHUAT01-it shows any network connection from the box; the old version showed successful connection to the vendor site; new version doesn’t show that it tried (there was no time wait line which would mean trying to connect; there was no connect line, which means connected-neither appeared).

                        Comment


                        • #13
                          This issue was sent to Mirth Support on July 3. Does anyone here happen to know an ETA for when this can get resolved?

                          Comment


                          • #14
                            Originally posted by phatneff View Post
                            This issue was sent to Mirth Support on July 3. Does anyone here happen to know an ETA for when this can get resolved?
                            My understanding of the SLA's are:
                            • Priority 1 - 60 min
                            • Priority 2 - 120 min
                            • Priority 3 - 720 min
                            • Priority 4 - 1440 min


                            I believe that is for a response, not a resolution. Are they actively engaged? If not, I would escalate.
                            SIG|1|Brad|Mirth Certified Interface Analyst^Cancer Treatment Centers of America

                            Comment


                            • #15
                              Can you show your destination configuration that is having the error?

                              Comment

                              Working...
                              X