FastCGI problem

Hello,

while i load test my lighttpd fascgi cluster, often get
overlapping
requests like that:

2006-04-28 17:40:42: (mod_fastcgi.c.2900) got proc: pid: 0
socket:
tcp:192.168.100.1:8000 load: 1
2006-04-28 17:40:42: (mod_fastcgi.c.2900) got proc: pid: 0
socket:
tcp:192.168.100.2:8000 load: 1
2006-04-28 17:40:42: (mod_fastcgi.c.1511) released proc:
pid: 0 socket:
tcp:192.168.100.2:8000 load: 0
2006-04-28 17:40:42: (mod_fastcgi.c.1511) released proc:
pid: 0 socket:
tcp:192.168.100.1:8000 load: 0

The problem is, that only one client gets its requested
page, the other
one gets a blank page, means a truncated response.

I played around the whole day with several configurations
but have still
no idea to avoid it. Does anyone had this problem before?

Ciao,
Norman

-- 
Norman Timmler

http://blog.inlet-media.de

Am Freitag, den 28.04.2006, 17:45 +0200 schrieb Norman
Timmler:

> while i load test my lighttpd fascgi cluster, often get
overlapping
> requests like that:
> 
> 2006-04-28 17:40:42: (mod_fastcgi.c.2900) got proc:
pid: 0 socket:
> tcp:192.168.100.1:8000 load: 1
> 2006-04-28 17:40:42: (mod_fastcgi.c.2900) got proc:
pid: 0 socket:
> tcp:192.168.100.2:8000 load: 1
> 2006-04-28 17:40:42: (mod_fastcgi.c.1511) released
proc: pid: 0
socket:
> tcp:192.168.100.2:8000 load: 0
> 2006-04-28 17:40:42: (mod_fastcgi.c.1511) released
proc: pid: 0
socket:
> tcp:192.168.100.1:8000 load: 0
> 
> The problem is, that only one client gets its requested
page, the
other
> one gets a blank page, means a truncated response.
> 
> I played around the whole day with several
configurations but have
still
> no idea to avoid it. Does anyone had this problem
before?



Here is a little more detailed log excerpt:

--- snip
2006-04-28 17:49:13: (mod_fastcgi.c.2900) got proc: pid: 0
socket:
tcp:192.168.100.1:8000 load: 1
2006-04-28 17:49:13: (mod_fastcgi.c.2900) got proc: pid: 0
socket:
tcp:192.168.100.2:8000 load: 1
2006-04-28 17:49:13: (mod_fastcgi.c.1511) released proc:
pid: 0 socket:
tcp:192.168.100.2:8000 load: 0
2006-04-28 17:49:13: (response.c.111) Response-Header:
HTTP/1.1 200 OK
Content-Length: 0
Date: Fri, 28 Apr 2006 15:49:13 GMT
Server: lighttpd/1.4.11


2006-04-28 17:49:13: (response.c.111) Response-Header:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Set-Cookie: _session_id=840a3b378ea49bdee4e74f52aff6c5f6;
path=/
Cache-Control: no-cache
Date: Fri, 28 Apr 2006 15:49:13 GMT
Server: lighttpd/1.4.11


2006-04-28 17:49:13: (mod_fastcgi.c.1511) released proc:
pid: 0 socket:
tcp:192.168.100.1:8000 load: 0
-- snap

You can see, that the first client gets only a 200 OK with
no content.


-- 
Norman Timmler

http://blog.inlet-media.de

Sorry about the spam, but the problem was a permission
failure on the
second application server causing Rails to not get a
database connection
and therefore no chance to load the sessions from the DB.
That results
in a so called 'white-screen of death' in Rails. Lighttpd
is working as
expected.
-- 
Norman Timmler

http://blog.inlet-media.de