www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: general/885: After a period of time (not found to coincide with server rehashes or any specific access), the server will read requests, but return no data (and close the connection). It will still respond to a server-status request though.
Date Wed, 19 Nov 1997 02:40:00 GMT
The following reply was made to PR general/885; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Illuminatus Primus <vermont@gate.net>
Cc: apbugs@apache.org
Subject: Re: general/885: After a period of time (not found to coincide with server rehashes
or any specific access), the server will read requests, but return no data (and close the
connection).  It will still respond to a server-status request though.
Date: Tue, 18 Nov 1997 18:36:37 -0800 (PST)

 On Fri, 14 Nov 1997, Illuminatus Primus wrote:
 
 > Yes, I realize that ap_slack tries to return the original fd if a new one
 > cannot be allocated, but unforunately if there are lots of fds open and
 > fcntl fails to remap the fd on a 2.0.29 kernel, it will return a closed fd
 > :).. maybe i misworded the sentence about open() returning -1 once in a
 > while..
 
 I don't see this wrong behaviour at all.  You mentioned this output
 for 2.0.29:
 
 On 2.0.29 (ISS patch #4), this is the behavior right before it
  reaches it's descriptor limit:
  myfd: 3 slacked up: 253
  myfd: 3 slacked up: 254
  myfd: 3 slacked up: 255
  myfd: 3 slacked up: 3
  myfd: 4 slacked up: 4
  myfd: 5 slacked up: 5
  myfd: 6 slacked up: 6
  myfd: 7 slacked up: 7
  myfd: 8 slacked up: 8
  myfd: 9 slacked up: 9
  myfd: 10 slacked up: 10
  myfd: 11 slacked up: 11
  myfd: 12 slacked up: 12
  myfd: 13 slacked up: 13
  myfd: 14 slacked up: 14
  myfd: -1 slacked up: -1
 
 This is perfectly correct behaviour.  file descriptor 3 is closed during
 all the cases where ap_slack successfully moves it.  When it fails, it
 returns 3 without closing it.  Nothing looks wrong.
 
 The difference with 2.1.x is that it supports more descriptors per
 process, but you also have to increase the system-wide number of files.
 Something like "echo 4096 >/proc/sys/kernel/file-max" will do the trick.
 Either that or you can "limit descriptors 64" and test with a smaller
 number per task.
 
 Dean
 

Mime
View raw message