After installaing 2.0.47 ab doesn't work any more: it blocks after connecting to remote machine: > This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.1 $> apache-2.0 > Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ > Benchmarking www.XXXX.com (be patient)... until getting a: > Benchmarking www.XXXX.com (be patient)...apr_poll: The timeout specified has expired (70007) Stracing ab says: > connect(3, {sin_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("217.9.XXX.XXX")}}, 16) = -1 EINPROGRESS (Operation now in progress) > gettimeofday({1057921957, 161482}, NULL) = 0 > poll( <unfinished ...> I "Ctrl-C"ed here. I assume it's not a matter of ab but a problem in one of the apr-shared libs ab is using: libaprutil-0.so.0 or libapr-0.so.0. If I use the libs from 2.0.46 the ab from 2.0.47 works fine. Hoping this is a real bug and not just a problem of my system. I tested it with SuSE 8.1 and Debian 2.0. Greetings from Germany, Kai Seidler
I can verify this problem with ab from Apache 2.1-dev on RedHat 8. Interestingly, apr_poll() hasn't changed in some time. And yet ab hasn't changed its use of socket I/O in some time either. Go figure :) Apparently the use of poll in ab is broken, as polling only for POLLIN is only going to catch failures to connect. Give this a spin (it works for me). Index: ab.c =================================================================== RCS file: /home/cvs/httpd-2.0/support/ab.c,v retrieving revision 1.126 diff -u -r1.126 ab.c --- ab.c 10 Jul 2003 19:16:35 -0000 1.126 +++ ab.c 11 Jul 2003 11:32:52 -0000 @@ -1268,7 +1268,7 @@ c->state = STATE_CONNECTING; c->rwrite = 0; new_pollfd.desc_type = APR_POLL_SOCKET; - new_pollfd.reqevents = APR_POLLIN; + new_pollfd.reqevents = APR_POLLIN | APR_POLLOUT; new_pollfd.desc.s = c->aprsock; new_pollfd.client_data = c; apr_pollset_add(readbits, &new_pollfd); I rarely use ab myself, and the only testing of it that I did personally over the last few releases has been over loopback, where I assume the connect completed synchronously and we didn't need to poll() until it completed.
Yes, it works for me as well. Thanks a lot, Jeff!
For the record: While the patch I posted apparently makes it work, it is something of a kludge. ab in 2.0.46 worked because of the way that apr_connect() was broken for purely non-blocking sockets. One would think that the poll condition between the initial connect call and when we know we've successfully found a partner would be simply POLLOUT, but it doesn't work unless you have POLLOUT|POLLIN because the connect state is used for more than just getting connected to the desired remote part. Another issue is that we don't reissue the connect to find out whether or not it worked. But that isn't so easy because connect state is overloaded with some SSL setup. Maybe the kludge isn't so bad, since it may be some time before somebody feels like cleaning house in ab and potentially breaking something else :)
*** Bug 22686 has been marked as a duplicate of this bug. ***
A fix for this will be in 2.0.48.