Interface connection not connecting

Check with your networking folks.  If they have changed any persistence settings in your switch or router settings, the connection may be dropped without either side knowing about it.

Sounds like when your lab system cycles their interface, the TCP/IP disconnect message is not getting to Cloverleaf for whatever reason.  Is it communicating fine right up to the point to where it’s cycled or have things gone south even before it’s cycled?  If it’s communicating fine until they interface is cycled I’d say the lab system has changed something, if it started backing up before the interface is cycled then I’d start looking at the network.

If you can reproduce it you could have your network guys put a sniffer on it and see what’s happening to the disconnect message.

I used to have a similar issue with SCC lab I put an alert in that would restart or you could write a script Kron or .bat and schedule to run at a certain time.

Soft can be configured to connect only when it has a trans and disconnect right after.  We’ve set it that way, and don’t run into the “gone away” issue.

I’m working with a client implementing an interface from Allscripts to SCC.  The situation is as follows:

1.  Connection is up and data is flowing

2.  Connection is dropped on the Allscripts side

3.  Cloverleaf shows in an up and connected state.

4.  It does not appear that Cloverleaf receives the network disconnect message so the connection remains up and Allscripts shows that they cannot connect during this time period.

5.  Eventually the connection is reestablished.

The network resource from the client site is running wireshark and thinks that he doesn’t see the network disconnect.

The Allscripts server is a hosted server, it is behind a firewall.  

We’ve tried keep alive messages configured to send every 15 minutes from Allscripts, but this doesn’t appear to help.

The network resource asked me to ping this group and see if you have any other suggestions as to how to further diagnose this issue.

Any help is appreciated.

Jill Marcotte

We have a similiar issue with our lab system after thier backups run every night. We have alerts set so after so long with no messages it cycles the thread and messages start to flow.

We have the same issue with a few of our vendor connections (including allscripts).  When the receiving system drops without sending the disconnect message, it is sometimes in the middle of a message being sent.  Cloverleaf is waiting for an ACK before sending another message, and the receiving system can’t connect to send the ACK.

We have it setup to cycle the connections on these specific ones when this happens, and then alert us if it still can’t send the messages.

This is typical of the disconnect message from the remote side not being received by your end. You can verify it by running netstat from the system prompt and looking for “FIN_WAIT_2” status for the relevant port.

If you haven’t already, you should ask Allscripts where their timeout is set on their server and any equipment on their side of the connection. Also investigate any routers/switches on your end. You should set your keepalive to a value smaller than the smallest of the others.