Cloverleafinterface to AtStaff

[Amol Kulkarni]

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

Topic

[John Hamilton]

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.

[Tom Rioux]

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

[Amol Kulkarni]

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

[John Hamilton]

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

[Tom Rioux]

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

[Amol Kulkarni]

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

[John Hamilton]

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.

[Mary Kobis]

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