A new -current has been uploaded. It tries to do better in autodetecting the 
correct flags/library for the compilation with threads support and 
auto-defines NEED_STACK if possible. As alway - let us know...[...]

Hi....

this version does not run well on debian.
it looses connections to the backend on with the gfx server ist on and there 
are sometimes header errors.
the server has
Requests: 95 req/s
 Traffic : 164 kb/s

This does not happen on older pound versions.

Greets

Alex
----- Original Message ----- 
From: "Robert Segall" <roseg(at)apsis.ch>
To: <pound(at)apsis.ch>
Sent: Friday, September 03, 2004 3:27 PM
Subject: New -current

[...]

On 3 Sep 2004, at 15:39, Alexander Meis wrote:
[...]
Same here with current - still losing backend connections within 30 
seconds of startup, even with two backend servers. I'm wondering if 
that's partly because I'm turning it on and it's immediately getting 
completely swamped by accesses. I will try again tomorrow, starting it 
up well before the hordes start beating on our door...

\[...]

definitely not happy: starting it up with around 300 anticipated hits 
second I just get loads of

Sep  4 13:36:41 new-master pound: MONITOR: worker exited on signal 11, 
restarting...

On Friday 03 September 2004 16.39, Alexander Meis wrote:[...]

Hate to ask the obvious, but did you set the Server value? One of the main 
differences between -current and 1.7 is the time-out on connect(), which uses 
the Server timeout (or 5 seconds if Server is not set). On a busy machine you 
could easily go over this, the connect() fails and the back-end is considered 
to be dead.[...]

On Saturday 04 September 2004 15.38, Mike Whitaker wrote:[...]

Losing back-end connections: see my previous post re. setting the Server 
value.

Bombing on SEGV is a problem. About the only changes between this and the 
previous -current are in setting the thread stack size and threading flags 
auto-detection. I suggest you try the following:

- increase the allocated stack size to more than 256K

- if that doesn't help remove the -DNEED_STACK altogether

- if that also doesn't help make sure you have -lpthread in your linking phase

Please let me know.[...]

On 6 Sep 2004, at 12:40, Robert Segall wrote:[...]

Shoot me now :)

On Monday 06 September 2004 13.48, Mike Whitaker wrote:[...]

Careful what you wish for.

Do I take it that it helped?[...]

>> Shoot me now :)[...]

Stress testing it shortly. :)

On 6 Sep 2004, at 13:28, Mike Whitaker wrote:

>>> Shoot me now :)[...]
[...]

Not good:

pound.cfg

User            www-data
Group           www-data
ExtendedHTTP    0
WebDAV          0
LogLevel        3
Alive           30
Server 10
ListenHTTP 127.0.0.1,80
UrlGroup ".*"
BackEnd 195.157.47.34,80,1
EndGroup

using apachebench:

ab -n 1000 -c 100 http://localhost/spacer.gif

I get

Sep  6 12:57:27 new-master pound: MONITOR: worker exited on signal 11, 
restarting...

as soon as I hit return on the command, pretty much, at which point it 
fails to find the backend server

Running with pthreads_attr_stacksize of 1 << 20 (2048)

Running the ab on the backend direct works fine (at well over 2000/s).

> using apachebench:[...]

In fact the very first request causes the worker to sig 11.

>[...]

I suspect the root of the problem is that I'm using Linux 2.6 and NPTL,
rather than libpth2. I'm very willing to help in any way I can to get 
this fixed.

On Monday 06 September 2004 15.58, Mike Whitaker wrote:[...]

What Linux? We are using NPTL with SuSE 9.1 and Gentoo and it works really 
well - no SEGV or any other problems, much better performance. We know of 
some serious issues with RedHat - search the mailing list archive for 
previous posts on this.

Could it be that you link with some strange libraries? Most often we have seen 
this sort of problem on *BSD, where OpenSSL is without thread support by 
default. Some people have tried to install a properly compiled OpenSSL, Pound 
compiled fine but at run-time it used the system dynamic library (without 
threads), which of course bombed. The solution was to link with the static 
libraries - gcc ... /usr/local/ssl/lib/libssl.a rather than gcc ... -lssl

Another thing to look into is the LD_ASSUME_KERNEL, which, if used, can force 
it to revert to the old threading package.[...]