Graham Dumpleton wrote:
Graham Dumpleton wrote ..
On 23/03/2006, at 5:06 AM, Jim Gallacher wrote:
That's another reason to rewrite the unit tests. It's too hard to
sort out the wheat from the chaff.
I don't think this is related to your failing test, but I noticed
the following, repeated numerous times throughout your log:
[Wed Mar 22 09:09:30 2006] [info] [client 127.0.0.1] (32)Broken
pipe: core_output_filter: writing data to the network
I think we need to investigate this one.
That is the error I was getting from ab in Apache 2.2. Change test.py to
explicitly use ab from Apache 2.0 and see if they go away.
Here is the previous information I posted about core_input_filter
errors caused by ab test tool in Apache 2.2.
http://www.mail-archive.com/python-dev@httpd.apache.org/msg01535.html
I only had it occur once for each test run and specifically the
global lock test, since that is the only place ab is used. Thus
cause may be different this time.
I'd forgotten about that conversation, but digging further into the test
I don't think that is the problem.
I'm unable to reproduce the error on Debian sid when using the ab that
comes with apache2.2, compiled from source.
Furthermore, the global_lock test is a PerInstanceTestCase. An apache
restart occurs between these tests, and as part of this the test setup
deletes the logs (which I think is the wrong thing to do, but
anyway...). As a result, the error_log file we see when all the tests
have completed is actually the log for the final PerInstanceTestCase,
which happens to be the big testPerRequestTests. The logs are lost for
the 5 test cases run prior to testPerRequestTests, including the
global_lock error log. As a result any error associated with this test
will *not* appear in the final error log, so the core_input_filter log
entry is not likely related to the using the wrong ab.
I fear we are depending on unit tests that may not be completely valid -
we've certainly come across enough examples of tests that passed but
which should have failed, or have other weird behaviour. I think it's
time to take a hard look at our unit test design. A review and possible
refactoring should be a priority before an eventual 3.3 release.
Jim
