Phil Steitz a écrit : > sebb wrote: >> On 31/12/2009, Phil Steitz <phil.ste...@gmail.com> wrote: >>> Comments have not changed sebb's -1, so I am going to consider this >>> a failed VOTE and roll another RC with documentation fixes already >>> made included and attempt at clearer release notes and README. >>> >>> Thanks, all for review and sorry to take so long to get this right. >> Please note that I am still seeing the occasional test failures (even >> after the test bug fix). >> As a result, I did not revisit the -1 for the compilation problems - >> the test failure seems like a -1 to me as well. > > In that case, I am honestly inclined to just remove / disable the > tests. As I said before, they are fragile and frankly half-baked. > Unfortunately, they did uncover a real bug recently, so I am of two > minds on this. > > What is going on in the most recent failure you reported (line 376 > of TestPerUserPoolDataSource) is a ThreadGroup is started launching > 2 * maxActive threads, all of which try to get connections, hold > them for (sic) 1 ms and then release them. MaxWait is 100 ms and > maxActive is 10. This "should" work as the effective throughput > should be ~10 requests / ms (that assumes perfect efficiency and no > execution time, which is not quite right), so 20 requests should > complete in ~20 ms. The test waits 100 ms. Given the fact that > perfect efficiency is obviously unrealistic, you can see that > especially with bad clock resolution and poor thread management > performance (Windoz is known for both), this is going to fail now > and then. FWIW, I have not seen a failure on OS X or Ubuntu (as OS X > guest) since sebb's last patch. > > Barring objections, I am leaning toward removing the tests.
I agree with you. Tests that are kept in the source distribution should be very reliable so they can be used blindly by users as regression tests if they want to modify our code to meet their needs and check they didn't break anything. So removing unreliable tests seems fair to me. Luc > > Phil >> I hope to try and look at the failures again tomorrow. >> >> It would be helpful if others could try running the failing test as >> well (you'll need a script to do this as it only fails about 1% of the >> time or less) >> >>> Phil >>> >>> Phil Steitz wrote: >>> > Hopefully all problems with JDK versions and the site build have now >>> > been resolved. As previously discussed, the only difference between >>> > 1.3 and 1.4 is that the 1.3 sources have been filtered to exclude >>> > JDBC4 methods. Version 1.3 is for JDK 1.4-1.5 and only builds under >>> > one of these JDKs. Note that to execute the 1.3 maven build under >>> > JDK 1.4 you need a 2.0.x version of maven. >>> > >>> > Here are the artifacts: >>> > >>> > 1.3 (JDBC 3) version: >>> > http://people.apache.org/~psteitz/dbcp-1.3-rc6 >>> > http://people.apache.org/~psteitz/dbcp-1.3-rc6/site >>> > http://people.apache.org/~psteitz/dbcp-1.3-rc6/maven >>> > http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_3_RC6/ >>> > >>> > 1.4 (JDBC 4) version: >>> > http://people.apache.org/~psteitz/dbcp-1.4-rc6 >>> > http://people.apache.org/~psteitz/dbcp-1.4-rc6/site >>> > http://people.apache.org/~psteitz/dbcp-1.4-rc6/maven >>> > http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC6/ >>> > >>> > Release notes (common version, ships with both) >>> > http://people.apache.org/~psteitz/RELEASE-NOTES.txt >>> > >>> > Votes, please. This VOTE will close 01-January-2010 03:30 GMT. >>> > >>> > [ ] +1 Proceed with release >>> > [ ] +0 OK >>> > [ ] -0 OK, but I would prefer... >>> > [ ] -1 No, showstopper = ... >>> > >>> > Thanks! >>> > >>> > Phil >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
