Clovertech

Cloverleafinterface to AtStaff

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Cloverleafinterface to AtStaff

  • Creator
    Topic
  • March 20, 2008 at 7:17 pm #49919
    Amol Kulkarni
    Participant

      Help, this particular vendor is driving me up the wall.

      We have a simple ADT interface with AtStaff. In a given day the ATStaff receiver drops out and reconnects. When this occurs, the message that has left Cloverleaf is lost.

      I do have Recover 38 in place and is working perfect.

      The vendor contiues to claim that the interface engine is switching off the AtStaff receiver. This is impossible action from the engine side.

      Does anyone have this product and is there something I am missing.

      Any assistance would be welcom.

      As always thanks for your help.

      Amol Kulkarni

      Mount Sinai Medical Center

      NY

    • Creator
      Topic
    Viewing 7 reply threads
    • Author
      Replies
      • March 20, 2008 at 7:24 pm #64096
        John Hamilton
        Participant

          I think what you need to do is turn smat on for both the inbound and outbound on that connections. Then show them the response you got for the message they claim is lost.

          If you can try to run an IPtrace which would show you exactly what happened and who disconnected from whom.  

          Either one of those I have found helpful when vendors try to claim things I know can’t be happening.  Or it proves them right either way you have proof as to what is failing and why.

        • March 20, 2008 at 8:17 pm #64097
          Tom Rioux
          Participant

            A couple of questions I have for you:

            1.  Is there a firewall between you and the vendor?

            2.  What is the volume of activity between your engine and the vendors system?  Are there periods of inactivity?

            Depending upon your volume with this system, it may be that the firewall is dropping the connection due to inactivity.  There is a setting that your network folks can tweak to allow this connection to stay active.

            Hope this helps…

            Tom Rioux

          • March 20, 2008 at 8:35 pm #64098
            Amol Kulkarni
            Participant

              Thomas, reply to your questions:

              1.  Is there a firewall between you and the vendor?  –> No, the server is in the Medical Center.

              2.  What is the volume of activity between your engine and the vendors system?  Are there periods of inactivity? –> There are periods of inactivity during the day.

              My understanding is that a receiver basically is always up and listening.

              When I did check system logs in the Vendors application, the log states dropping connection and then restarting.

              Thanks

              amol

            • March 20, 2008 at 8:57 pm #64099
              John Hamilton
              Participant

                Is the question why are we connecting and disconnecting or why are we missing a message ?

              • March 20, 2008 at 8:59 pm #64100
                Tom Rioux
                Participant

                  Are these UNIX boxes?  If so, have your UNIX administrator check to see what the TCP_KEEPALIVE is set to.  It may be the connection is timing out due to the setting not being high enough.  If you do indeed have periods of inactivity, then this setting may need to be bumped up.

                  Thanks…

                  Tom Rioux

                • March 21, 2008 at 11:57 am #64101
                  Amol Kulkarni
                  Participant

                    Reply to John’s question: Yes, I can not figure out why are we showing in the AtStaff Service Log, connecting and disconnect. This pattern continues throughout the day; meanwhile I have 100+ connections using the same mlp driver and these do not have similar behaviour.

                    thanks

                  • March 21, 2008 at 1:34 pm #64102
                    John Hamilton
                    Participant

                      Ok, I was a little confused as to why this would concern the recovery procs.

                      There are many ways the connetions can be broken. Tom is on the correct path for some of them.  But as many system there are I think that is as many ways a connetion can be broken.

                      They best way to find the real issue is a network trace. If you are a Unix box you can do that yourself as root. But if not you will need to get the Network guys involved and do a network trace between the two boxes.

                      Either seems to be a lot of trouble, if you are not lossing messagse and the connections come back when you need to send data, I’m not sure I would consider it broken.

                    • March 25, 2008 at 4:00 pm #64103
                      Mary Kobis
                      Participant

                        We have a vendor here doing the same. After investigating why the connection disconnects, via the IPtrace as John suggested, we found the problem. The vendor sends an TCP ‘abort’ disconnect after sending the ACK and then reopens the connection. In the meantime, Cloverleaf is sending the second message when the abort hits the cloverleaf socket. Once the thread’s auto-reconnect processes Cloverleaf resends the message. Then it starts all over again. I’ve tweaked the outbound thread’s auto-reconnect to 3 seconds and await replies to 5 seconds. It works good, but we will get a 10-12 messages backlog during peak times.

                        I have argued and recited the TCP/IP WIKI with documentation on the disconnect to the vendor, but I’m talking to deaf ears, so I gave up…

                        BTW, the TCP/IP WIKI is a great source on the codes used to communicate and a good read.

                        Hope this helps a little, Mary

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