In addition, there is a Microsoft Tech Note stating this registry entry
is *NOT* present to the registry , and the default value is 2 hours.
This explains why the failure point of the delay occurred between 1 and
2 hours of being idle.

 

http://technet2.microsoft.com/windowsserver/en/library/af2e0d81-50cc-430
d-80e1-a2ccebfc68f21033.mspx?mfr=true

 


KeepAliveTime


Updated: March 28, 2003

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

Data type

Range

Default value

REG_DWORD

0x1-0xFFFFFFFF (milliseconds)

0x6DDD00 (7,200,000 milliseconds = 2 hours)


Description


Specifies how often TCP sends keep-alive transmissions. TCP sends
keep-alive transmissions to verify that an idle connection is still
active.

This entry is used when the remote system is responding to TCP.
Otherwise, the interval between transmissions is determined by the value
of the Parameters\KeepAliveInterval
<http://technet2.microsoft.com/WindowsServer/en/library/734570a2-06d6-45
0e-b765-ccfa7530af491033.mspx>  entry.

By default, keep-alive transmissions are not sent. The TCP keep-alive
feature must be enabled by a program (such as Telnet), or by an Internet
browser (such as Internet Explorer).

Note

* Windows Server 2003 does not add this entry to the registry. You can
add it by using the registry editor Regedit.exe.

        

 

 

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Worthington
Sent: Wednesday, January 09, 2008 12:47 PM
To: arslist@ARSLIST.ORG
Subject: Re: Delays after user tool sits idle

 

** 
Wow... Matt.  Thanks for the information!  I'm going to have to pass
this along to our network folks.  This might also fix our issues with
our load-balancers not being able to track sessions that aren't
persistent with a keep-alive (Remedy.)

Thanks again!

Tony 


-- 
Tony Worthington
Sr. Technical Analyst
Kohl's Department Stores
[EMAIL PROTECTED]
262-703-5911 



Matt Reinfeldt <[EMAIL PROTECTED]> 
Sent by: "Action Request System discussion list(ARSList)"
<arslist@ARSLIST.ORG> 

01/09/2008 11:04 AM 

Please respond to
arslist@ARSLIST.ORG

To

arslist@ARSLIST.ORG 

cc

        
Subject

Re: Delays after user tool sits idle

 

                




** 
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 Key:
<http://www.pctools.com/guides/help/registry-settings.php#system_key>
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters]
Value Name:
<http://www.pctools.com/guides/help/registry-settings.php#value_name>
KeepAliveTime, KeepAliveInterval
Data Type:
<http://www.pctools.com/guides/help/registry-settings.php#data_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 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___


This message is subject to and does not create or vary any contractual 
relationship between TuringSMI, SMI Technologies, SMI Telco, its subsidiaries 
or affiliates and you. Internet communications are not secure and therefore the 
TuringSMI Group does not accept any legal responsibility for the contents of 
this message. Any views or opinions expressed are those of the author.  This 
message is intended for the addressee ('s) only and its contents and any 
attached files are strictly confidential. If you have received it in error, 
please contact the sender on the number above.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to