[continuum] BUILD FAILURE: Commons - Commons DBCP - Java 5 Ant build
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267250&projectId=22 Build statistics: State: Failed Previous State: Error Started at: Fri 8 Jan 2010 06:29:25 -0800 Finished at: Fri 8 Jan 2010 06:29:34 -0800 Total time: 9s Build Trigger: Schedule Build Number: 133 Exit code: 127 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Apache Ant version 1.7.0 compiled on December 13 2006 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: Ant build filename: build.xml Goals: clean test Arguments: -Dcomponent-propfile=build.properties.sample Build Fresh: false Always Build: false Default Build Definition: false Schedule: COMMONS_SCHEDULE Profile Name: Ant 1.7.0, Java 5 Description: Java 5 Ant build Test Summary: Tests: 445 Failures: 1 Errors: 0 Success Rate: 99 Total time: 51.457996 Test Failures: TestSharedPoolDataSource testMultipleThreads2 : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: WARNING: Expected half the threads to fail expected:<10> but was:<7> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.apache.commons.dbcp.TestConnectionPool.multipleThreads(TestConnectionPool.java:766) at org.apache.commons.dbcp.datasources.TestSharedPoolDataSource.testMultipleThreads2(TestSharedPoolDataSource.java:375) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Commons - Commons DBCP - Java 5 Ant build
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267362&projectId=22 Build statistics: State: Failed Previous State: Error Started at: Fri 8 Jan 2010 10:52:02 -0800 Finished at: Fri 8 Jan 2010 10:52:09 -0800 Total time: 7s Build Trigger: Schedule Build Number: 133 Exit code: 127 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Apache Ant version 1.7.0 compiled on December 13 2006 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: Ant build filename: build.xml Goals: clean test Arguments: -Dcomponent-propfile=build.properties.sample Build Fresh: false Always Build: false Default Build Definition: false Schedule: COMMONS_SCHEDULE Profile Name: Ant 1.7.0, Java 5 Description: Java 5 Ant build Test Summary: Tests: 445 Failures: 1 Errors: 0 Success Rate: 99 Total time: 51.457996 Test Failures: TestSharedPoolDataSource testMultipleThreads2 : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: WARNING: Expected half the threads to fail expected:<10> but was:<7> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.apache.commons.dbcp.TestConnectionPool.multipleThreads(TestConnectionPool.java:766) at org.apache.commons.dbcp.datasources.TestSharedPoolDataSource.testMultipleThreads2(TestSharedPoolDataSource.java:375) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Commons - Commons DBCP - Java 5 Ant build
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267398&projectId=22 Build statistics: State: Failed Previous State: Error Started at: Sun 10 Jan 2010 07:29:15 -0800 Finished at: Sun 10 Jan 2010 07:29:24 -0800 Total time: 8s Build Trigger: Forced Build Number: 133 Exit code: 127 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Apache Ant version 1.7.0 compiled on December 13 2006 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: Ant build filename: build.xml Goals: clean test Arguments: -Dcomponent-propfile=build.properties.sample Build Fresh: false Always Build: false Default Build Definition: false Schedule: COMMONS_SCHEDULE Profile Name: Ant 1.7.0, Java 5 Description: Java 5 Ant build Test Summary: Tests: 445 Failures: 1 Errors: 0 Success Rate: 99 Total time: 51.457996 Test Failures: TestSharedPoolDataSource testMultipleThreads2 : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: WARNING: Expected half the threads to fail expected:<10> but was:<7> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.apache.commons.dbcp.TestConnectionPool.multipleThreads(TestConnectionPool.java:766) at org.apache.commons.dbcp.datasources.TestSharedPoolDataSource.testMultipleThreads2(TestSharedPoolDataSource.java:375) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r897678 - in /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp: TestConnectionPool.java datasources/TestPerUserPoolDataSource.java datasources/TestSharedPoolDataSource.java
>From the debugging added to some previously failed builds, I saw
loop = 2 for some threads. Threads should not be looping. Second
loop by a thread that succeeded the first time that throws will not
change success state - so it looks like a success -> not enough
failures.
Phil
pste...@apache.org wrote:
> Author: psteitz
> Date: Sun Jan 10 18:21:03 2010
> New Revision: 897678
>
> URL: http://svn.apache.org/viewvc?rev=897678&view=rev
> Log:
> Eliminated unintended looping in mutipleThreads test.
>
> Modified:
>
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
>
> Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
> ==
> ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> (original)
> +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> Sun Jan 10 18:21:03 2010
> @@ -683,7 +683,21 @@
> }
> }
>
> -protected void multipleThreads(final int holdTime, final boolean
> expectError, long maxWait)
> +/**
> + * Launches a group of 2 * getMaxActive() threads, each of which will
> attempt to obtain a connection
> + * from the pool, hold it for ms, and then return it to the
> pool. If is false,
> + * threads will continue this process indefinitely. If
> is true, exactly 1/2 of the
> + * threads are expected to either throw exceptions or fail to complete.
> If is false,
> + * all threads are expected to complete successfully.
> + *
> + * @param holdTime time in ms that a thread holds a connection before
> returning it to the pool
> + * @param expectError whether or not an error is expected
> + * @param loopOnce whether threads should complete the borrow - hold -
> return cycle only once, or loop indefinitely
> + * @param maxWait passed in by client - has no impact on the test
> itself, but does get reported
> + *
> + * @throws Exception
> + */
> +protected void multipleThreads(final int holdTime, final boolean
> expectError, final boolean loopOnce, final long maxWait)
> throws Exception {
> long startTime = timeStamp();
> final PoolTest[] pts = new PoolTest[2 * getMaxActive()];
> @@ -696,8 +710,7 @@
> }
> };
> for (int i = 0; i < pts.length; i++) {
> -// If we are expecting an error, don't allow successful
> threads to loop
> -(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError)).start();
> +(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError, loopOnce)).start();
> }
>
> Thread.sleep(100L); // Wait for long enough to allow threads
> to start
>
> Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
> ==
> ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> (original)
> +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> Sun Jan 10 18:21:03 2010
> @@ -378,11 +378,11 @@
> final int defaultMaxWait = 430;
> ((PerUserPoolDataSource) ds).setDefaultMaxWait(defaultMaxWait);
> ((PerUserPoolDataSource) ds).setPerUserMaxWait("foo",new
> Integer(defaultMaxWait));
> -multipleThreads(1, false, defaultMaxWait);
> +multipleThreads(1, false, false, defaultMaxWait);
> }
>
> public void testMultipleThreads2() throws Exception {
> -multipleThreads(2 * (int)(getMaxWait()), true, getMaxWait());
> +multipleThreads(2 * (int)(getMaxWait()), true, false, getMaxWait());
> }
>
> public void testTransactionIsolationBehavior() throws Exception {
>
> Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
> ===
[continuum] BUILD SUCCESSFUL: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267471&projectId=22 Build statistics: State: Ok Previous State: Failed Started at: Sun 10 Jan 2010 10:53:50 -0800 Finished at: Sun 10 Jan 2010 10:55:38 -0800 Total time: 1m 47s Build Trigger: Forced Build Number: 134 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.6.0_06 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 445 Failures: 0 Errors: 0 Success Rate: 100 Total time: 47.390003 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Commons - Commons DBCP - Java 5 Ant build
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267522&projectId=22 Build statistics: State: Failed Previous State: Error Started at: Sun 10 Jan 2010 13:13:43 -0800 Finished at: Sun 10 Jan 2010 13:13:50 -0800 Total time: 6s Build Trigger: Forced Build Number: 134 Exit code: 127 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Apache Ant version 1.7.0 compiled on December 13 2006 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: Ant build filename: build.xml Goals: clean test Arguments: -Dcomponent-propfile=build.properties.sample Build Fresh: false Always Build: false Default Build Definition: false Schedule: NEVER Profile Name: Ant 1.7.0, Java 5 Description: Java 5 Ant build Test Summary: Tests: 445 Failures: 0 Errors: 0 Success Rate: 100 Total time: 47.390003 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r897678 - in /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp: TestConnectionPool.java datasources/TestPerUserPoolDataSource.java datasources/TestSharedPoolDataSource.java
Thanks.
Looks like I did not complete the fixes properly when I added the
loopOnce parameter to PoolTest.
It was quite tricky following the Continuum build output, as the date
was 2 days behind, and the mail for the failed runs is not always
accurate - if the "Exit code" is 127, then most of the email contents
is inaccurate.
I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
misleading info.
On 10/01/2010, Phil Steitz wrote:
> From the debugging added to some previously failed builds, I saw
> loop = 2 for some threads. Threads should not be looping. Second
> loop by a thread that succeeded the first time that throws will not
> change success state - so it looks like a success -> not enough
> failures.
>
> Phil
>
>
> pste...@apache.org wrote:
> > Author: psteitz
> > Date: Sun Jan 10 18:21:03 2010
> > New Revision: 897678
> >
> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
> > Log:
> > Eliminated unintended looping in mutipleThreads test.
> >
> > Modified:
> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
> >
> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
> >
> ==
> > ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> (original)
> > +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> Sun Jan 10 18:21:03 2010
> > @@ -683,7 +683,21 @@
> > }
> > }
> >
> > -protected void multipleThreads(final int holdTime, final boolean
> expectError, long maxWait)
> > +/**
> > + * Launches a group of 2 * getMaxActive() threads, each of which will
> attempt to obtain a connection
> > + * from the pool, hold it for ms, and then return it to
> the pool. If is false,
> > + * threads will continue this process indefinitely. If
> is true, exactly 1/2 of the
> > + * threads are expected to either throw exceptions or fail to
> complete. If is false,
> > + * all threads are expected to complete successfully.
> > + *
> > + * @param holdTime time in ms that a thread holds a connection before
> returning it to the pool
> > + * @param expectError whether or not an error is expected
> > + * @param loopOnce whether threads should complete the borrow - hold
> - return cycle only once, or loop indefinitely
> > + * @param maxWait passed in by client - has no impact on the test
> itself, but does get reported
> > + *
> > + * @throws Exception
> > + */
> > +protected void multipleThreads(final int holdTime, final boolean
> expectError, final boolean loopOnce, final long maxWait)
> > throws Exception {
> > long startTime = timeStamp();
> > final PoolTest[] pts = new PoolTest[2 * getMaxActive()];
> > @@ -696,8 +710,7 @@
> > }
> > };
> > for (int i = 0; i < pts.length; i++) {
> > -// If we are expecting an error, don't allow
> successful threads to loop
> > -(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError)).start();
> > +(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError, loopOnce)).start();
> > }
> >
> > Thread.sleep(100L); // Wait for long enough to allow
> threads to start
> >
> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
> >
> ==
> > ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> (original)
> > +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> Sun Jan 10 18:21:03 2010
> > @@ -378,11 +378,11 @@
> > final int defaultMaxWait = 430;
> > ((PerUserPoolDataSource) ds).setDefaultMaxWait(defaultMaxWait);
> > ((PerUserPoolDataSource) ds).setPerUserMaxWait("foo",new
> Integer(defaultMaxWait));
> > -multipleThreads(1, false, defaultMaxWait);
> > +multipleThreads(1, false, false, defaultMaxWait);
> > }
> >
> >
Re: svn commit: r897678 - in /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp: TestConnectionPool.java datasources/TestPerUserPoolDataSource.java datasources/TestSharedPoolDataSource.java
sebb wrote:
> Thanks.
>
> Looks like I did not complete the fixes properly when I added the
> loopOnce parameter to PoolTest.
>
> It was quite tricky following the Continuum build output, as the date
> was 2 days behind, and the mail for the failed runs is not always
> accurate - if the "Exit code" is 127, then most of the email contents
> is inaccurate.
>
> I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
> misleading info.
This could be complicated by my attempts at implementing the Ant
Java 5 build snd also the combination of forced and scheduled builds.
Phil
>
> On 10/01/2010, Phil Steitz wrote:
>> From the debugging added to some previously failed builds, I saw
>> loop = 2 for some threads. Threads should not be looping. Second
>> loop by a thread that succeeded the first time that throws will not
>> change success state - so it looks like a success -> not enough
>> failures.
>>
>> Phil
>>
>>
>> pste...@apache.org wrote:
>> > Author: psteitz
>> > Date: Sun Jan 10 18:21:03 2010
>> > New Revision: 897678
>> >
>> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
>> > Log:
>> > Eliminated unintended looping in mutipleThreads test.
>> >
>> > Modified:
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
>> >
>> > Modified:
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
>> >
>> ==
>> > ---
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> (original)
>> > +++
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> Sun Jan 10 18:21:03 2010
>> > @@ -683,7 +683,21 @@
>> > }
>> > }
>> >
>> > -protected void multipleThreads(final int holdTime, final boolean
>> expectError, long maxWait)
>> > +/**
>> > + * Launches a group of 2 * getMaxActive() threads, each of which
>> will attempt to obtain a connection
>> > + * from the pool, hold it for ms, and then return it to
>> the pool. If is false,
>> > + * threads will continue this process indefinitely. If
>> is true, exactly 1/2 of the
>> > + * threads are expected to either throw exceptions or fail to
>> complete. If is false,
>> > + * all threads are expected to complete successfully.
>> > + *
>> > + * @param holdTime time in ms that a thread holds a connection
>> before returning it to the pool
>> > + * @param expectError whether or not an error is expected
>> > + * @param loopOnce whether threads should complete the borrow - hold
>> - return cycle only once, or loop indefinitely
>> > + * @param maxWait passed in by client - has no impact on the test
>> itself, but does get reported
>> > + *
>> > + * @throws Exception
>> > + */
>> > +protected void multipleThreads(final int holdTime, final boolean
>> expectError, final boolean loopOnce, final long maxWait)
>> > throws Exception {
>> > long startTime = timeStamp();
>> > final PoolTest[] pts = new PoolTest[2 * getMaxActive()];
>> > @@ -696,8 +710,7 @@
>> > }
>> > };
>> > for (int i = 0; i < pts.length; i++) {
>> > -// If we are expecting an error, don't allow
>> successful threads to loop
>> > -(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError)).start();
>> > +(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError, loopOnce)).start();
>> > }
>> >
>> > Thread.sleep(100L); // Wait for long enough to allow
>> threads to start
>> >
>> > Modified:
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
>> >
>> ==
>> > ---
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> (original)
>> > +++
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> Sun Jan 10 18:21:03 2010
>> > @@ -378,11 +378,11 @@
>> > final int defaultMaxWait = 430;
>> > ((PerUserPoolDataSource)
Re: svn commit: r897678 - in /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp: TestConnectionPool.java datasources/TestPerUserPoolDataSource.java datasources/TestSharedPoolDataSource.java
On 10/01/2010, Phil Steitz wrote:
> sebb wrote:
> > Thanks.
> >
> > Looks like I did not complete the fixes properly when I added the
> > loopOnce parameter to PoolTest.
> >
> > It was quite tricky following the Continuum build output, as the date
> > was 2 days behind, and the mail for the failed runs is not always
> > accurate - if the "Exit code" is 127, then most of the email contents
> > is inaccurate.
> >
> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
> > misleading info.
>
>
> This could be complicated by my attempts at implementing the Ant
> Java 5 build snd also the combination of forced and scheduled builds.
>
That part I found easy enough to follow, but Continuum clearly didn't ... !
> Phil
>
>
> >
> > On 10/01/2010, Phil Steitz wrote:
> >> From the debugging added to some previously failed builds, I saw
> >> loop = 2 for some threads. Threads should not be looping. Second
> >> loop by a thread that succeeded the first time that throws will not
> >> change success state - so it looks like a success -> not enough
> >> failures.
> >>
> >> Phil
> >>
> >>
> >> pste...@apache.org wrote:
> >> > Author: psteitz
> >> > Date: Sun Jan 10 18:21:03 2010
> >> > New Revision: 897678
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
> >> > Log:
> >> > Eliminated unintended looping in mutipleThreads test.
> >> >
> >> > Modified:
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
> >> >
> >> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> >> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
> >> >
> ==
> >> > ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> (original)
> >> > +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> Sun Jan 10 18:21:03 2010
> >> > @@ -683,7 +683,21 @@
> >> > }
> >> > }
> >> >
> >> > -protected void multipleThreads(final int holdTime, final boolean
> expectError, long maxWait)
> >> > +/**
> >> > + * Launches a group of 2 * getMaxActive() threads, each of which
> will attempt to obtain a connection
> >> > + * from the pool, hold it for ms, and then return it
> to the pool. If is false,
> >> > + * threads will continue this process indefinitely. If
> is true, exactly 1/2 of the
> >> > + * threads are expected to either throw exceptions or fail to
> complete. If is false,
> >> > + * all threads are expected to complete successfully.
> >> > + *
> >> > + * @param holdTime time in ms that a thread holds a connection
> before returning it to the pool
> >> > + * @param expectError whether or not an error is expected
> >> > + * @param loopOnce whether threads should complete the borrow -
> hold - return cycle only once, or loop indefinitely
> >> > + * @param maxWait passed in by client - has no impact on the test
> itself, but does get reported
> >> > + *
> >> > + * @throws Exception
> >> > + */
> >> > +protected void multipleThreads(final int holdTime, final boolean
> expectError, final boolean loopOnce, final long maxWait)
> >> > throws Exception {
> >> > long startTime = timeStamp();
> >> > final PoolTest[] pts = new PoolTest[2 *
> getMaxActive()];
> >> > @@ -696,8 +710,7 @@
> >> > }
> >> > };
> >> > for (int i = 0; i < pts.length; i++) {
> >> > -// If we are expecting an error, don't allow
> successful threads to loop
> >> > -(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError)).start();
> >> > +(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError, loopOnce)).start();
> >> > }
> >> >
> >> > Thread.sleep(100L); // Wait for long enough to allow
> threads to start
> >> >
> >> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> >> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
> >> >
> ==
> >> > ---
> commons/proper/dbcp/trunk/src/tes
[dbcp] multipleThreads test
sebb wrote:
> Thanks.
>
> Looks like I did not complete the fixes properly when I added the
> loopOnce parameter to PoolTest.
I think I found (and fixed) another problem. See r897720.
>
> It was quite tricky following the Continuum build output, as the date
> was 2 days behind, and the mail for the failed runs is not always
> accurate - if the "Exit code" is 127, then most of the email contents
> is inaccurate.
>
> I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
> misleading info.
>
> On 10/01/2010, Phil Steitz wrote:
>> From the debugging added to some previously failed builds, I saw
>> loop = 2 for some threads. Threads should not be looping. Second
>> loop by a thread that succeeded the first time that throws will not
>> change success state - so it looks like a success -> not enough
>> failures.
>>
>> Phil
>>
>>
>> pste...@apache.org wrote:
>> > Author: psteitz
>> > Date: Sun Jan 10 18:21:03 2010
>> > New Revision: 897678
>> >
>> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
>> > Log:
>> > Eliminated unintended looping in mutipleThreads test.
>> >
>> > Modified:
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
>> >
>> > Modified:
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
>> >
>> ==
>> > ---
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> (original)
>> > +++
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> Sun Jan 10 18:21:03 2010
>> > @@ -683,7 +683,21 @@
>> > }
>> > }
>> >
>> > -protected void multipleThreads(final int holdTime, final boolean
>> expectError, long maxWait)
>> > +/**
>> > + * Launches a group of 2 * getMaxActive() threads, each of which
>> will attempt to obtain a connection
>> > + * from the pool, hold it for ms, and then return it to
>> the pool. If is false,
>> > + * threads will continue this process indefinitely. If
>> is true, exactly 1/2 of the
>> > + * threads are expected to either throw exceptions or fail to
>> complete. If is false,
>> > + * all threads are expected to complete successfully.
>> > + *
>> > + * @param holdTime time in ms that a thread holds a connection
>> before returning it to the pool
>> > + * @param expectError whether or not an error is expected
>> > + * @param loopOnce whether threads should complete the borrow - hold
>> - return cycle only once, or loop indefinitely
>> > + * @param maxWait passed in by client - has no impact on the test
>> itself, but does get reported
>> > + *
>> > + * @throws Exception
>> > + */
>> > +protected void multipleThreads(final int holdTime, final boolean
>> expectError, final boolean loopOnce, final long maxWait)
>> > throws Exception {
>> > long startTime = timeStamp();
>> > final PoolTest[] pts = new PoolTest[2 * getMaxActive()];
>> > @@ -696,8 +710,7 @@
>> > }
>> > };
>> > for (int i = 0; i < pts.length; i++) {
>> > -// If we are expecting an error, don't allow
>> successful threads to loop
>> > -(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError)).start();
>> > +(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError, loopOnce)).start();
>> > }
>> >
>> > Thread.sleep(100L); // Wait for long enough to allow
>> threads to start
>> >
>> > Modified:
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
>> >
>> ==
>> > ---
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> (original)
>> > +++
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> Sun Jan 10 18:21:03 2010
>> > @@ -378,11 +378,11 @@
>> > final int defaultMaxWait = 430;
>> > ((PerUserPoolDataSource) ds).setDefaultMaxWait(defaultMaxWait);
>> > ((PerUserPoolDataSource) ds
Re: [dbcp] multipleThreads test
On 10/01/2010, Phil Steitz wrote:
> sebb wrote:
> > Thanks.
> >
> > Looks like I did not complete the fixes properly when I added the
> > loopOnce parameter to PoolTest.
>
> I think I found (and fixed) another problem. See r897720.
The wait in question is purely to allow the threads to start, so I
think it should not depend on the value of maxWait (or indeed
holdTime). Originally it was set to 10L * holdTime, which meant that
it did always not work well for holdTime = 1.
> >
> > It was quite tricky following the Continuum build output, as the date
> > was 2 days behind, and the mail for the failed runs is not always
> > accurate - if the "Exit code" is 127, then most of the email contents
> > is inaccurate.
> >
> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
> > misleading info.
> >
> > On 10/01/2010, Phil Steitz wrote:
> >> From the debugging added to some previously failed builds, I saw
> >> loop = 2 for some threads. Threads should not be looping. Second
> >> loop by a thread that succeeded the first time that throws will not
> >> change success state - so it looks like a success -> not enough
> >> failures.
> >>
> >> Phil
> >>
> >>
> >> pste...@apache.org wrote:
> >> > Author: psteitz
> >> > Date: Sun Jan 10 18:21:03 2010
> >> > New Revision: 897678
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
> >> > Log:
> >> > Eliminated unintended looping in mutipleThreads test.
> >> >
> >> > Modified:
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> >> >
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
> >> >
> >> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> >> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
> >> >
> ==
> >> > ---
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> (original)
> >> > +++
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
> Sun Jan 10 18:21:03 2010
> >> > @@ -683,7 +683,21 @@
> >> > }
> >> > }
> >> >
> >> > -protected void multipleThreads(final int holdTime, final boolean
> expectError, long maxWait)
> >> > +/**
> >> > + * Launches a group of 2 * getMaxActive() threads, each of which
> will attempt to obtain a connection
> >> > + * from the pool, hold it for ms, and then return it
> to the pool. If is false,
> >> > + * threads will continue this process indefinitely. If
> is true, exactly 1/2 of the
> >> > + * threads are expected to either throw exceptions or fail to
> complete. If is false,
> >> > + * all threads are expected to complete successfully.
> >> > + *
> >> > + * @param holdTime time in ms that a thread holds a connection
> before returning it to the pool
> >> > + * @param expectError whether or not an error is expected
> >> > + * @param loopOnce whether threads should complete the borrow -
> hold - return cycle only once, or loop indefinitely
> >> > + * @param maxWait passed in by client - has no impact on the test
> itself, but does get reported
> >> > + *
> >> > + * @throws Exception
> >> > + */
> >> > +protected void multipleThreads(final int holdTime, final boolean
> expectError, final boolean loopOnce, final long maxWait)
> >> > throws Exception {
> >> > long startTime = timeStamp();
> >> > final PoolTest[] pts = new PoolTest[2 *
> getMaxActive()];
> >> > @@ -696,8 +710,7 @@
> >> > }
> >> > };
> >> > for (int i = 0; i < pts.length; i++) {
> >> > -// If we are expecting an error, don't allow
> successful threads to loop
> >> > -(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError)).start();
> >> > +(pts[i] = new PoolTest(threadGroup, holdTime,
> expectError, loopOnce)).start();
> >> > }
> >> >
> >> > Thread.sleep(100L); // Wait for long enough to allow
> threads to start
> >> >
> >> > Modified:
> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
> >> > URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java?rev=897678&r1=897677&r2=897678&view=diff
> >> >
> ===
Re: [dbcp] multipleThreads test
sebb wrote:
> On 10/01/2010, Phil Steitz wrote:
>> sebb wrote:
>> > Thanks.
>> >
>> > Looks like I did not complete the fixes properly when I added the
>> > loopOnce parameter to PoolTest.
>>
>> I think I found (and fixed) another problem. See r897720.
>
> The wait in question is purely to allow the threads to start, so I
> think it should not depend on the value of maxWait (or indeed
> holdTime). Originally it was set to 10L * holdTime, which meant that
> it did always not work well for holdTime = 1.
OK, then I must be missing something. Since stop can interrupt run,
it would seem to me that entering the stop loop immediately after
this wait is going to stop all of the threads, giving them all just
whatever the wait is to complete. That, I was assuming, is why the
1.2.2 version waited 10 * holdTime, which would not really have been
quite right - better a function of maxWait.
Phil
>
>> >
>> > It was quite tricky following the Continuum build output, as the date
>> > was 2 days behind, and the mail for the failed runs is not always
>> > accurate - if the "Exit code" is 127, then most of the email contents
>> > is inaccurate.
>> >
>> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the
>> > misleading info.
>> >
>> > On 10/01/2010, Phil Steitz wrote:
>> >> From the debugging added to some previously failed builds, I saw
>> >> loop = 2 for some threads. Threads should not be looping. Second
>> >> loop by a thread that succeeded the first time that throws will not
>> >> change success state - so it looks like a success -> not enough
>> >> failures.
>> >>
>> >> Phil
>> >>
>> >>
>> >> pste...@apache.org wrote:
>> >> > Author: psteitz
>> >> > Date: Sun Jan 10 18:21:03 2010
>> >> > New Revision: 897678
>> >> >
>> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev
>> >> > Log:
>> >> > Eliminated unintended looping in mutipleThreads test.
>> >> >
>> >> > Modified:
>> >> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> >> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
>> >> >
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java
>> >> >
>> >> > Modified:
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> >> > URL:
>> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff
>> >> >
>> ==
>> >> > ---
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> (original)
>> >> > +++
>> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java
>> Sun Jan 10 18:21:03 2010
>> >> > @@ -683,7 +683,21 @@
>> >> > }
>> >> > }
>> >> >
>> >> > -protected void multipleThreads(final int holdTime, final boolean
>> expectError, long maxWait)
>> >> > +/**
>> >> > + * Launches a group of 2 * getMaxActive() threads, each of which
>> will attempt to obtain a connection
>> >> > + * from the pool, hold it for ms, and then return it
>> to the pool. If is false,
>> >> > + * threads will continue this process indefinitely. If
>> is true, exactly 1/2 of the
>> >> > + * threads are expected to either throw exceptions or fail to
>> complete. If is false,
>> >> > + * all threads are expected to complete successfully.
>> >> > + *
>> >> > + * @param holdTime time in ms that a thread holds a connection
>> before returning it to the pool
>> >> > + * @param expectError whether or not an error is expected
>> >> > + * @param loopOnce whether threads should complete the borrow -
>> hold - return cycle only once, or loop indefinitely
>> >> > + * @param maxWait passed in by client - has no impact on the
>> test itself, but does get reported
>> >> > + *
>> >> > + * @throws Exception
>> >> > + */
>> >> > +protected void multipleThreads(final int holdTime, final boolean
>> expectError, final boolean loopOnce, final long maxWait)
>> >> > throws Exception {
>> >> > long startTime = timeStamp();
>> >> > final PoolTest[] pts = new PoolTest[2 *
>> getMaxActive()];
>> >> > @@ -696,8 +710,7 @@
>> >> > }
>> >> > };
>> >> > for (int i = 0; i < pts.length; i++) {
>> >> > -// If we are expecting an error, don't allow
>> successful threads to loop
>> >> > -(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError)).start();
>> >> > +(pts[i] = new PoolTest(threadGroup, holdTime,
>> expectError, loopOnce)).start();
>> >> >
Re: [dbcp] multipleThreads test
On 10/01/2010, Phil Steitz wrote: > sebb wrote: > > On 10/01/2010, Phil Steitz wrote: > >> sebb wrote: > >> > Thanks. > >> > > >> > Looks like I did not complete the fixes properly when I added the > >> > loopOnce parameter to PoolTest. > >> > >> I think I found (and fixed) another problem. See r897720. > > > > The wait in question is purely to allow the threads to start, so I > > think it should not depend on the value of maxWait (or indeed > > holdTime). Originally it was set to 10L * holdTime, which meant that > > it did always not work well for holdTime = 1. > > > OK, then I must be missing something. Since stop can interrupt run, > it would seem to me that entering the stop loop immediately after > this wait is going to stop all of the threads, giving them all just > whatever the wait is to complete. In the case where the loop only operates once, so long as the wait time is long enough to allow all the threads to start then it won't affect further processing of the PoolTest threads. However if it is much longer than maxWait or holdTime, the test will take longer than necessary. For the multi-loop case, the wait time must again be enough to allow the threads to start. This guarantees that the threads will run at least once. The overall run-time of the test (and the number of loops) is controlled by the wait time, because the holdTime is very short in comparison. > That, I was assuming, is why the > 1.2.2 version waited 10 * holdTime, which would not really have been > quite right - better a function of maxWait. The 1.2.2 version also handled completion differently - it did not wait for the threads to complete, and it did not have a loopOnce option. Provided that maxWait expired before holdTime, then at least one thread would fail, and this would stop all the threads. But this was not always happening, so I introduced the loopOnce parameter. > > Phil > > > > > >> > > >> > It was quite tricky following the Continuum build output, as the date > >> > was 2 days behind, and the mail for the failed runs is not always > >> > accurate - if the "Exit code" is 127, then most of the email contents > >> > is inaccurate. > >> > > >> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the > >> > misleading info. > >> > > >> > On 10/01/2010, Phil Steitz wrote: > >> >> From the debugging added to some previously failed builds, I saw > >> >> loop = 2 for some threads. Threads should not be looping. Second > >> >> loop by a thread that succeeded the first time that throws will not > >> >> change success state - so it looks like a success -> not enough > >> >> failures. > >> >> > >> >> Phil > >> >> > >> >> > >> >> pste...@apache.org wrote: > >> >> > Author: psteitz > >> >> > Date: Sun Jan 10 18:21:03 2010 > >> >> > New Revision: 897678 > >> >> > > >> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev > >> >> > Log: > >> >> > Eliminated unintended looping in mutipleThreads test. > >> >> > > >> >> > Modified: > >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java > >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java > >> >> > > >> >> > Modified: > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > >> >> > URL: > http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff > >> >> > > == > >> >> > --- > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > (original) > >> >> > +++ > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > Sun Jan 10 18:21:03 2010 > >> >> > @@ -683,7 +683,21 @@ > >> >> > } > >> >> > } > >> >> > > >> >> > -protected void multipleThreads(final int holdTime, final > boolean expectError, long maxWait) > >> >> > +/** > >> >> > + * Launches a group of 2 * getMaxActive() threads, each of > which will attempt to obtain a connection > >> >> > + * from the pool, hold it for ms, and then return > it to the pool. If is false, > >> >> > + * threads will continue this process indefinitely. If > is true, exactly 1/2 of the > >> >> > + * threads are expected to either throw exceptions or fail to > complete. If is false, > >> >> > + * all threads are expected to complete successfully. > >> >> > + * > >> >> > + * @param holdTime time in ms that a thread holds a > connection before returning it to the pool > >> >> > + * @param expectError whether or not an err
[continuum] BUILD FAILURE: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267564&projectId=22 Build statistics: State: Failed Previous State: Ok Started at: Sun 10 Jan 2010 15:13:35 -0800 Finished at: Sun 10 Jan 2010 15:15:26 -0800 Total time: 1m 50s Build Trigger: Forced Build Number: 134 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.6.0_06 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: Changed: psteitz @ Sun 10 Jan 2010 14:07:16 -0800 Comment: Allow threads sufficient time to complete in multipleThreads. Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java ( 897720 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 445 Failures: 1 Errors: 0 Success Rate: 99 Total time: 52.4 Test Failures: TestSharedPoolDataSource testMultipleThreads2 : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: Expected some of the threads to fail at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.dbcp.TestConnectionPool.multipleThreads(TestConnectionPool.java:763) at org.apache.commons.dbcp.datasources.TestSharedPoolDataSource.testMultipleThreads2(TestSharedPoolDataSource.java:375) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[DBCP] Continuum Java 5 build
It is starting to look like Continuum cannot handle mixed Maven and Ant groups, so perhaps it would be worth experimenting with a standalone group? Or perhaps work out how to use Maven to build with Java 1.4/1.5 (which would be useful anyway) ;-) I've tried recreating the failures using Hudson, but failed. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] multipleThreads test
sebb wrote: > On 10/01/2010, Phil Steitz wrote: >> sebb wrote: >> > On 10/01/2010, Phil Steitz wrote: >> >> sebb wrote: >> >> > Thanks. >> >> > >> >> > Looks like I did not complete the fixes properly when I added the >> >> > loopOnce parameter to PoolTest. >> >> >> >> I think I found (and fixed) another problem. See r897720. >> > >> > The wait in question is purely to allow the threads to start, so I >> > think it should not depend on the value of maxWait (or indeed >> > holdTime). Originally it was set to 10L * holdTime, which meant that >> > it did always not work well for holdTime = 1. >> >> >> OK, then I must be missing something. Since stop can interrupt run, >> it would seem to me that entering the stop loop immediately after >> this wait is going to stop all of the threads, giving them all just >> whatever the wait is to complete. > > In the case where the loop only operates once, so long as the wait > time is long enough to allow all the threads to start then it won't > affect further processing of the PoolTest threads. However if it is > much longer than maxWait or holdTime, the test will take longer than > necessary. > > For the multi-loop case, the wait time must again be enough to allow > the threads to start. This guarantees that the threads will run at > least once. The overall run-time of the test (and the number of loops) > is controlled by the wait time, because the holdTime is very short in > comparison. You are right. Sorry. Phil > >> That, I was assuming, is why the >> 1.2.2 version waited 10 * holdTime, which would not really have been >> quite right - better a function of maxWait. > > The 1.2.2 version also handled completion differently - it did not > wait for the threads to complete, and it did not have a loopOnce > option. Provided that maxWait expired before holdTime, then at least > one thread would fail, and this would stop all the threads. But this > was not always happening, so I introduced the loopOnce parameter. > >> Phil >> >> >> > >> >> > >> >> > It was quite tricky following the Continuum build output, as the date >> >> > was 2 days behind, and the mail for the failed runs is not always >> >> > accurate - if the "Exit code" is 127, then most of the email contents >> >> > is inaccurate. >> >> > >> >> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for the >> >> > misleading info. >> >> > >> >> > On 10/01/2010, Phil Steitz wrote: >> >> >> From the debugging added to some previously failed builds, I saw >> >> >> loop = 2 for some threads. Threads should not be looping. Second >> >> >> loop by a thread that succeeded the first time that throws will not >> >> >> change success state - so it looks like a success -> not enough >> >> >> failures. >> >> >> >> >> >> Phil >> >> >> >> >> >> >> >> >> pste...@apache.org wrote: >> >> >> > Author: psteitz >> >> >> > Date: Sun Jan 10 18:21:03 2010 >> >> >> > New Revision: 897678 >> >> >> > >> >> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev >> >> >> > Log: >> >> >> > Eliminated unintended looping in mutipleThreads test. >> >> >> > >> >> >> > Modified: >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java >> >> >> > >> >> >> > Modified: >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> >> >> > URL: >> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff >> >> >> > >> == >> >> >> > --- >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> (original) >> >> >> > +++ >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> Sun Jan 10 18:21:03 2010 >> >> >> > @@ -683,7 +683,21 @@ >> >> >> > } >> >> >> > } >> >> >> > >> >> >> > -protected void multipleThreads(final int holdTime, final >> boolean expectError, long maxWait) >> >> >> > +/** >> >> >> > + * Launches a group of 2 * getMaxActive() threads, each of >> which will attempt to obtain a connection >> >> >> > + * from the pool, hold it for ms, and then return >> it to the pool. If is false, >> >> >> > + * threads will continue this process indefinitely. If >> is true, exactly 1/2 of the >> >> >> > + * threads are expected to either throw exceptions or fail >> to complete. If is false, >> >> >> > + * all threads are expected to complete successfully. >> >> >> > + * >>
Re: [DBCP] Continuum Java 5 build
sebb wrote: > It is starting to look like Continuum cannot handle mixed Maven and > Ant groups, so perhaps it would be worth experimenting with a > standalone group? That may be what we have to do. It doesn't make sense, since there is a "build environment" object that should determine what happens. I am starting to think this is a bug with the way continuum sets up ant builds inside projects that have a default maven build. I will investigate. Modulo the right setting for the initial wait on multipleThreads and reverting the nanotime thing, do you think we are ready for another RC? Phil > > Or perhaps work out how to use Maven to build with Java 1.4/1.5 (which > would be useful anyway) ;-) > > I've tried recreating the failures using Hudson, but failed. > > - > 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
Re: [dbcp] multipleThreads test
On 10/01/2010, Phil Steitz wrote: > sebb wrote: > > On 10/01/2010, Phil Steitz wrote: > >> sebb wrote: > >> > On 10/01/2010, Phil Steitz wrote: > >> >> sebb wrote: > >> >> > Thanks. > >> >> > > >> >> > Looks like I did not complete the fixes properly when I added the > >> >> > loopOnce parameter to PoolTest. > >> >> > >> >> I think I found (and fixed) another problem. See r897720. > >> > > >> > The wait in question is purely to allow the threads to start, so I > >> > think it should not depend on the value of maxWait (or indeed > >> > holdTime). Originally it was set to 10L * holdTime, which meant that > >> > it did always not work well for holdTime = 1. > >> > >> > >> OK, then I must be missing something. Since stop can interrupt run, > >> it would seem to me that entering the stop loop immediately after > >> this wait is going to stop all of the threads, giving them all just > >> whatever the wait is to complete. > > > > In the case where the loop only operates once, so long as the wait > > time is long enough to allow all the threads to start then it won't > > affect further processing of the PoolTest threads. However if it is > > much longer than maxWait or holdTime, the test will take longer than > > necessary. > > > > For the multi-loop case, the wait time must again be enough to allow > > the threads to start. This guarantees that the threads will run at > > least once. The overall run-time of the test (and the number of loops) > > is controlled by the wait time, because the holdTime is very short in > > comparison. > > > You are right. Sorry. No problem. It looks like only the testMaxWait() test now loops more that once. I think testMultipleThreads1() should also loop, as this will show that 20 threads can share 10 connections without problems. I'll fix that shortly. I'm not sure whether testMaxWait() needs to allow looping; however it should never do so as all threads will timeout. > > Phil > > > > >> That, I was assuming, is why the > >> 1.2.2 version waited 10 * holdTime, which would not really have been > >> quite right - better a function of maxWait. > > > > The 1.2.2 version also handled completion differently - it did not > > wait for the threads to complete, and it did not have a loopOnce > > option. Provided that maxWait expired before holdTime, then at least > > one thread would fail, and this would stop all the threads. But this > > was not always happening, so I introduced the loopOnce parameter. > > > >> Phil > >> > >> > >> > > >> >> > > >> >> > It was quite tricky following the Continuum build output, as the > date > >> >> > was 2 days behind, and the mail for the failed runs is not always > >> >> > accurate - if the "Exit code" is 127, then most of the email > contents > >> >> > is inaccurate. > >> >> > > >> >> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for > the > >> >> > misleading info. > >> >> > > >> >> > On 10/01/2010, Phil Steitz wrote: > >> >> >> From the debugging added to some previously failed builds, I saw > >> >> >> loop = 2 for some threads. Threads should not be looping. > Second > >> >> >> loop by a thread that succeeded the first time that throws will > not > >> >> >> change success state - so it looks like a success -> not enough > >> >> >> failures. > >> >> >> > >> >> >> Phil > >> >> >> > >> >> >> > >> >> >> pste...@apache.org wrote: > >> >> >> > Author: psteitz > >> >> >> > Date: Sun Jan 10 18:21:03 2010 > >> >> >> > New Revision: 897678 > >> >> >> > > >> >> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev > >> >> >> > Log: > >> >> >> > Eliminated unintended looping in mutipleThreads test. > >> >> >> > > >> >> >> > Modified: > >> >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > >> >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java > >> >> >> > > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java > >> >> >> > > >> >> >> > Modified: > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > >> >> >> > URL: > http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff > >> >> >> > > == > >> >> >> > --- > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > (original) > >> >> >> > +++ > commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java > Sun Jan 10 18:21:03 2010 > >> >> >> > @@ -683,7 +683,21 @@ > >> >> >> > } > >> >> >> > } > >> >> >> > > >> >> >>
Re: [dbcp] multipleThreads test
sebb wrote: > On 10/01/2010, Phil Steitz wrote: >> sebb wrote: >> > On 10/01/2010, Phil Steitz wrote: >> >> sebb wrote: >> >> > On 10/01/2010, Phil Steitz wrote: >> >> >> sebb wrote: >> >> >> > Thanks. >> >> >> > >> >> >> > Looks like I did not complete the fixes properly when I added the >> >> >> > loopOnce parameter to PoolTest. >> >> >> >> >> >> I think I found (and fixed) another problem. See r897720. >> >> > >> >> > The wait in question is purely to allow the threads to start, so I >> >> > think it should not depend on the value of maxWait (or indeed >> >> > holdTime). Originally it was set to 10L * holdTime, which meant that >> >> > it did always not work well for holdTime = 1. >> >> >> >> >> >> OK, then I must be missing something. Since stop can interrupt run, >> >> it would seem to me that entering the stop loop immediately after >> >> this wait is going to stop all of the threads, giving them all just >> >> whatever the wait is to complete. >> > >> > In the case where the loop only operates once, so long as the wait >> > time is long enough to allow all the threads to start then it won't >> > affect further processing of the PoolTest threads. However if it is >> > much longer than maxWait or holdTime, the test will take longer than >> > necessary. >> > >> > For the multi-loop case, the wait time must again be enough to allow >> > the threads to start. This guarantees that the threads will run at >> > least once. The overall run-time of the test (and the number of loops) >> > is controlled by the wait time, because the holdTime is very short in >> > comparison. >> >> >> You are right. Sorry. > > No problem. > > It looks like only the testMaxWait() test now loops more that once. > I think testMultipleThreads1() should also loop, as this will show > that 20 threads can share 10 connections without problems. I'll fix > that shortly. Yes. > > I'm not sure whether testMaxWait() needs to allow looping; however it > should never do so as all threads will timeout. Yes, I see no need for looping on this. Phil > > >> Phil >> >> >> That, I was assuming, is why the >> >> 1.2.2 version waited 10 * holdTime, which would not really have been >> >> quite right - better a function of maxWait. >> > >> > The 1.2.2 version also handled completion differently - it did not >> > wait for the threads to complete, and it did not have a loopOnce >> > option. Provided that maxWait expired before holdTime, then at least >> > one thread would fail, and this would stop all the threads. But this >> > was not always happening, so I introduced the loopOnce parameter. >> > >> >> Phil >> >> >> >> >> >> > >> >> >> > >> >> >> > It was quite tricky following the Continuum build output, as the >> date >> >> >> > was 2 days behind, and the mail for the failed runs is not always >> >> >> > accurate - if the "Exit code" is 127, then most of the email >> contents >> >> >> > is inaccurate. >> >> >> > >> >> >> > I have raised http://jira.codehaus.org/browse/CONTINUUM-2428 for >> the >> >> >> > misleading info. >> >> >> > >> >> >> > On 10/01/2010, Phil Steitz wrote: >> >> >> >> From the debugging added to some previously failed builds, I saw >> >> >> >> loop = 2 for some threads. Threads should not be looping. >> Second >> >> >> >> loop by a thread that succeeded the first time that throws will >> not >> >> >> >> change success state - so it looks like a success -> not enough >> >> >> >> failures. >> >> >> >> >> >> >> >> Phil >> >> >> >> >> >> >> >> >> >> >> >> pste...@apache.org wrote: >> >> >> >> > Author: psteitz >> >> >> >> > Date: Sun Jan 10 18:21:03 2010 >> >> >> >> > New Revision: 897678 >> >> >> >> > >> >> >> >> > URL: http://svn.apache.org/viewvc?rev=897678&view=rev >> >> >> >> > Log: >> >> >> >> > Eliminated unintended looping in mutipleThreads test. >> >> >> >> > >> >> >> >> > Modified: >> >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java >> >> >> >> > >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java >> >> >> >> > >> >> >> >> > Modified: >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> >> >> >> > URL: >> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java?rev=897678&r1=897677&r2=897678&view=diff >> >> >> >> > >> == >> >> >> >> > --- >> commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java >> (original) >> >> >> >> > +++ >> commons/proper/dbcp/trunk/src/test/org/ap
Re: [DBCP] Continuum Java 5 build
On 11/01/2010, Phil Steitz wrote: > sebb wrote: > > It is starting to look like Continuum cannot handle mixed Maven and > > Ant groups, so perhaps it would be worth experimenting with a > > standalone group? > > > That may be what we have to do. It doesn't make sense, since there > is a "build environment" object that should determine what happens. > I am starting to think this is a bug with the way continuum sets up > ant builds inside projects that have a default maven build. > > I will investigate. > > Modulo the right setting for the initial wait on multipleThreads and > reverting the nanotime thing, do you think we are ready for another RC? I'm not convinced that we have fixed the Continuum failures; ideally I'd like to see some successful Java 6 and Ant/Java 1.5 runs first. Also, I raised 2 JIRAs that could perhaps be fixed: DBCP-319 Make private fields final where possible There's a patch for this. DBCP-317 Findbugs: Class doesn't override equals in superclass The equals() overriding is inconsisent. > Phil > > > > > Or perhaps work out how to use Maven to build with Java 1.4/1.5 (which > > would be useful anyway) ;-) > > > > I've tried recreating the failures using Hudson, but failed. > > > > > - > > 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
Re: [DBCP] Continuum Java 5 build
On 11/01/2010, sebb wrote: > On 11/01/2010, Phil Steitz wrote: > > sebb wrote: > > > It is starting to look like Continuum cannot handle mixed Maven and > > > Ant groups, so perhaps it would be worth experimenting with a > > > standalone group? > > > > > > That may be what we have to do. It doesn't make sense, since there > > is a "build environment" object that should determine what happens. > > I am starting to think this is a bug with the way continuum sets up > > ant builds inside projects that have a default maven build. > > > > I will investigate. > > > > Modulo the right setting for the initial wait on multipleThreads and > > reverting the nanotime thing, do you think we are ready for another RC? > > > I'm not convinced that we have fixed the Continuum failures; ideally > I'd like to see some successful Java 6 and Ant/Java 1.5 runs first. In fact, the last Continuum/Maven/Java 6 build failed - all the threads completed successfully in TestSharedPoolDataSource.testMultipleThreads2(), but 10 should have failed. This was after your last fix: r897720 I've made 3 test fix commits since then. > Also, I raised 2 JIRAs that could perhaps be fixed: > > DBCP-319 Make private fields final where possible > There's a patch for this. > > DBCP-317 Findbugs: Class doesn't override equals in superclass > The equals() overriding is inconsisent. > > > > Phil > > > > > > > > Or perhaps work out how to use Maven to build with Java 1.4/1.5 (which > > > would be useful anyway) ;-) > > > > > > I've tried recreating the failures using Hudson, but failed. > > > > > > > > - > > > 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
[continuum] BUILD FAILURE: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267625&projectId=22 Build statistics: State: Failed Previous State: Failed Started at: Sun 10 Jan 2010 18:15:28 -0800 Finished at: Sun 10 Jan 2010 18:18:03 -0800 Total time: 2m 35s Build Trigger: Schedule Build Number: 134 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.6.0_06 OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix" SCM Changes: Changed: sebb @ Sun 10 Jan 2010 15:26:03 -0800 Comment: Move assertion so debug happens for case where all threads complete Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java ( 897731 ) Changed: sebb @ Sun 10 Jan 2010 15:55:37 -0800 Comment: Show total loop count just in case. Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java ( 897735 ) Changed: sebb @ Sun 10 Jan 2010 16:10:18 -0800 Comment: testMultipleThreads1() should allow looping (shows threads can share properly) Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java ( 897737 ) /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestSharedPoolDataSource.java ( 897737 ) Changed: sebb @ Sun 10 Jan 2010 16:12:58 -0800 Comment: Use fixed startup wait time Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java ( 897738 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 445 Failures: 1 Errors: 0 Success Rate: 99 Total time: 46.128 Test Failures: TestPerUserPoolDataSource testMultipleThreads2 : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: WARNING: Expected half the threads to fail expected:<10> but was:<9> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.apache.commons.dbcp.TestConnectionPool.multipleThreads(TestConnectionPool.java:786) at org.apache.commons.dbcp.datasources.TestPerUserPoolDataSource.testMultipleThreads2(TestPerUserPoolDataSource.java:385) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Divesting the commons.lang.math package
Without any further input (over a week), I say it's safe to divest. On Sun, Jan 3, 2010 at 5:58 AM, Luc Maisonobe wrote: > Henri Yandell a écrit : >> On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict wrote: >>> This is how I believe the commons.lang.math package can be eliminated. >>> Based on the current 3.0-SNAPSHOT API, there are only three classes >>> left: >>> >>> Fraction >>> IEEE754rUtils >>> NumberUtils >>> >>> 1) Fraction should leave; it is completely inappropriate for this >>> library. It has nothing to do with the JDK or supporting the Java >>> language. It belongs squarely in Commons Math. >>> 2) IEEE754rUtils should move to the root of commons.lang >>> 3) NumberUtils should move to the root of commons.lang >> >> We discussed Fraction being deleted earlier in 3.0, but the view was >> to keep it. I'm happy for it to go. [math]'s version appears to be >> practically the same. >> >> Half of NumberUtils is String conversion. The other half are min/max; >> which is what IEEE754Utils is. These could potentially move to >> [math]'s util.MathUtils. >> >> One advantage is that people looking for these minor methods would >> have an on ramp into the other components for the more powerful >> features. >> >> One concern I have is finding the basic functionality in another >> package. You go to [math] and it's all about the powerful deep things, >> not a random reusable bit of code off to the side. >> >> Maybe the right solution there is "Commons Common", with 80% reuse/20% >> power; or maybe the solution is documentation in which all the basic >> types of methods are collated and link to the components they're in. > > We probably lack good documentation on the basic utility parts in [math]. > > Luc > >> >> Hen >> >> - >> 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
