Outbound thread to STAR Registration looses connection

[Tim Wanner]

Summary:  Each morning approx 6:45, an outbound interface looses connection with McKesson STAR (sending schedule messages). There is no activity on this thread from approx 7:00 PM until 7:00 AM. There are no CRONS on either system at that time that would interfere. After the STAR side is bounced, the connection is re-established, and maintined until approx 6:45 the next day (+/- 10 minutes) I have turned on logging (enable all), and see events, but am unable to understand all of the events.  I’m looking for some interpertation of these events to determine which interface is causing the drop.

Any suggestions are apprecicated.

Topic

[Robert Gordon]

If its and outbound thread open the thread.  Click the outbound tab look for the section of await replies under the title “Timeout:” make sure it doesn’t say -1, but a value greater than 0.  Open the manual and read what this feature does.

[Rick Martin]

Hi Tim,

Did you find a resolution to this problem?  

We have a similar situation now with an external Cerner system.  We’ve gone from a batch delivery of results to a real-time (24×7) delivery.  Previously when we brought the outbound connection up/down once per day everything was fine, but now that the connection remains up; every morning we have to ask the Cerner client to reset their side to re-establish the connection.

Rick

[Tim Wanner]

No.  I know the Cloverleaf thread was not dropping, and couldn’t prove that the STAR interface was not.  We use a series of monitoring scripts, so I added one to bounce the process every 3 hours from 8:00 PM until 8:00 AM.  Since it was a scheduling interface, it was idle after hours. Problem has not returned.

[Daniel Lee]

Does your connection go through a VPN tunnel or is the server in house?  It sounds to me like it’s either a VPN problem or the receiving system isn’t doing TCP/IP correctly.

[Rick Martin]

In our case, it goes through a VPN tunnel, but we’ve had the network guru’s on both sides swear there is no VPN/timeout issue.

[Michael Hertel]

Read this thread it may be helpful:

https://usspvlclovertch2.infor.com/viewtopic.php?t=734&highlight=tcpkeepidle

[Chris Williams]

In Unix you definitely want to check your tcp-keepalive-interval setting. We’re on HP-UX 11i. The setting is kept in /etc/rc.config.d/nddconf. The default is 7200000 ms (2 hrs).

We had been having several similar problems with connections going down at odd times. One cause turned out to be a piece of Cisco equipment in the middle of things that was timing out.  I changed our Unix keepalive to 90000 ms (15 minutes), and we haven’t had a similar problem since.

Make the change in the file so it will be effective on the next reboot. Use ndd -c to update the system from the file without having to wait for the next reboot. Check the Unix man pages for more details.

Chris

[Author]

Replies