Clovertech

Non-persistant Connection – Server

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Non-persistant Connection – Server

  • Creator
    Topic
  • July 16, 2010 at 5:29 pm #51874
    Jared Parish
    Participant

      I have a vendor (MedOne Hospital Physicians) sending HL7 messages to Cloverleaf 5.7 Rev1 (redhat).  They’re stating they are getting a “Connection actively refused” error after trying to send the next message in their queue.  I have my side setup as a PDL-TCPIP server and to ACK each message.

          I ask how their system is setup/programmed.  They stated that they start a new connect for each message, wait for an ACK, then close. Repeat. I changed the Auto-reconnect reopen time to a lower setting.  That seems to have help, but, didn’t resolve the issue.

      Any Ideas?  Anybody worked with MedOne?  I don’t have a problem with any other inbound connect.

      …off to review documentation.

      - Jared Parish

    • Creator
      Topic
    Viewing 7 reply threads
    • Author
      Replies
      • July 16, 2010 at 6:25 pm #72094
        James Cobane
        Participant

          Jared,

          I would recommend changing your inbound connection to a multi-server configuration.  It is likely that they are not fully closing the connection before attempting to open it again.  By changing it to multi-server, you’ll allow them to connect again, even if the previous connection is still open (i.e. not fully closed).  You’ll need to modify your ack proc to ack back on the appropriate client connection.  Simply add the following line before before your return of the disposition list:

          msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

          (Assuming that $obMsg is the message handle of the reply you are sending back and $mh is the message handle of the inbound message)

          I’ve had to do this on a few threads for some vendors.

          Hope this helps.

          Jim Cobane

          Henry Ford Health

        • July 16, 2010 at 7:23 pm #72095
          Jared Parish
          Participant

            James,

                That worked perfectly.  Thanks for your help.

            Thanks very much,

            - Jared Parish

          • July 21, 2010 at 7:23 am #72096
            Richard Hart
            Participant

              Hi Jared.

              It may be an idea to close the connection after you’ve written the message, we are doing this now as we are testing the multi-server socket to see if it will replace the a Perl program that currently manages our mutli-socket interfaces.

              This works for normal sockets, BUT, there is a (relatively) large overhead loading the PDL when the port reopens!

              This can be accomplished, (in 5.6 and I guess higher) by ‘ticking’ the ‘Close after write’ box from the Thread Properties and using TCL to create a new message to close the connection.

              eg

                                 #

                                 # Send a message to close the port after use

                                 #

                             set myMsgPortClose [msgcreate]

                             set myDriverCtl {}

                             keylset myDriverCtl CLOSE 1

                             keylset myDriverCtl WRITEZERO 0

                             msgmetaset $myMsgPortClose DRIVERCTL $myDriverCtl

                            lappend myDispList “CONTINUE $myMsgPortClose”

            • September 8, 2010 at 7:38 pm #72097
              Paul Johnston
              Participant

                Hi Jim ,

                We are experiencing, I believe the same issue as Jared , and would like to try your solution .

                I am not a expert in TCL . I have added your line in my code ( below) . Can you confirm I have the correct location. ?  Hopefully I have included enough of the code .

                Code:

                …..

                #
                # Now build the ACKNOWLEGEMENT message
                #
                   set ACK “MSH$fldsep$sepchar$fldsep$rx_appl$fldsep$send_fac$fldsep”
                   append ACK “$send_appl$fldsep$rx_fac$fldsep$dttm$fldsep$fldsep$mtype$fldsep”
                   append ACK “$rx_ID$fldsep$p_type$fldsep$version$fldsep${seq_no}r”
                   append ACK “MSA$fldsep$ack_type$fldsep$rx_ID$fldsep${ack_msg}r”
                   set obMsg [msgcreate -type reply]
                   msgset $obMsg $ACK

                # NEW    msgmetaset $obMsg DRIVERCTL [msgmetaget $ACK DRIVERCTL]    

                #
                # Continue original message and send response
                # unless there was an error, then kill original
                #

                   if $ackflag {
                       return “{CONTINUE $mh} {OVER $obMsg}”
                   } else {
                       return “{KILL $mh} {OVER $obMsg}”
                   }

                ……

                Thanks for your help .

              • September 9, 2010 at 1:14 pm #72098
                James Cobane
                Participant

                  Paul,

                  I think you need to change the line

                  msgmetaset $obMsg DRIVERCTL [msgmetaget $ACK DRIVERCTL]

                   to

                  msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

                  to obtain the DRIVERCTL info from the original message.  Then, as long as you set the DRIVERCTL information prior to returning the disposition list, you should be good.

                  Jim Cobane

                  Henry Ford Health

                • September 14, 2010 at 1:43 pm #72099
                  Paul Johnston
                  Participant

                    Hi Jim ,

                    I have changed the line as you mentioned but I am not sure how to set the

                    DRIVERCTL information.  Do you have an example ?

                    Thanks again.

                  • September 14, 2010 at 2:33 pm #72100
                    James Cobane
                    Participant

                      Hi Paul,

                      The line that you changed to:

                      msgmetaset $obMsg DRIVERCTL [msgmetaget $mh DRIVERCTL]

                      will value the DRIVERCTL metadata of the reply message you are sending out with the appropriate information.  It captures the DRIVERCTL information of the original inbound message (assuming the $mh is the message handle of the original inbound message) and sets the DRIVERCTL information of your outbound reply (assuming $obMsg is the message handle of the created reply) appropriately.  With this information, the engine will send the reply back out to the client port that the inbound message was originally sent on.  So, that should do the trick!

                      Hope this helps.

                      Jim Cobane

                      Henry Ford Health

                    • September 14, 2010 at 6:27 pm #72101
                      Paul Johnston
                      Participant

                        Thanks again Jim ,

                        I understand the logic now with setting DRIVERCTL .

                        I have modifed our HL7 ACK tcl to include with the DRIVERCTL statement . It probably is working but after further investigation I believe we are experiencing a somewhat different issue.  I am examining it further.

                        Thanks for your help.

                    • Author
                      Replies
                    Viewing 7 reply threads
                    • The forum ‘Cloverleaf’ is closed to new topics and replies.