Tony,
Bryan Waters and I have been working with the escalation engineers on this, and we've seen the following fix resolve the issue: Apply the below Registry settings, if in a Windows environment, to each Windows server that hosts an AR Server. If the AR Server is on Linux/UNIX, see this note: "It is depend on the server platform. If it is Windows, I think the steps are same for server and client. If it is Linux, run echo "300" >/proc/sys/net/ipv4/tcp_keepalive_time (default is 7200, 2 hours) To confirm it works, use WireShark for Windows and tcpdump for Linux to monitor the connection between client and server. On every keepalive_time, server should send out an acknowledge packet to client and client sends reply back. In this way, connection is alive for another keepalive_time interval." Open your registry and find the key below. Create new DWORD value named "KeepAliveTime" and set it to equal the number of milliseconds to wait before sending keep alive packets (the default is 2 hours - 7,200,000 milliseconds). Also create a new DWORD value called "KeepAliveInterval" and set it to equal the time in milliseconds between retransmissions of keepalives, once the KeepAliveTime has expired (the default is 1 second - 1000 milliseconds). Restart Windows for the change to take effect. Registry Settings System <http://www.pctools.com/guides/help/registry-settings.php#system_key> Key: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters] Value <http://www.pctools.com/guides/help/registry-settings.php#value_name> Name: KeepAliveTime, KeepAliveInterval Data <http://www.pctools.com/guides/help/registry-settings.php#data_type> Type: REG_DWORD (DWORD Value) The KeepAliveTime would be set to 300000 for our test (5 minutes). If the Registry changes resolve the issue for you, we could export the settings from the dev server's Registry and simply import them to the production machines before rebooting them. KeepAliveTime set to 300000 KeepAliveInterval set to 5000 Anyway, long story short, it appears that some network device is killing the idle TCP connection after n-minutes (value depends on the device settings). So, the solution is to send a keep alive signal from the server more often than the default 2 hours, or identify the device causing the problems and change its settings. Hope that helps you with your issue. BTW: we've requested that a KB get written up for this, but I don't know when/if that will happen. Matt Reinfeldt _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tony Worthington Sent: Thursday, September 27, 2007 6:05 AM To: arslist@ARSLIST.ORG Subject: Re: Delays after user tool sits idle ** I think that's a good idea. ethereal+tcpdump should spit sometime out. At least more than the user tool logs. :-) I'll let everyone know what happens. Still no response from support.. -tony -- Tony Worthington Sr. Technical Analyst Kohl's Department Stores [EMAIL PROTECTED] 262-703-5911 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
