[continuum] BUILD FAILURE: Commons - Commons DBCP - Java 5 Ant build
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267250projectId=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=267362projectId=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=267398projectId=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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to the
pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If expectingError
is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to complete.
If expectingError 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=897678r1=897677r2=897678view=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=897678r1=897677r2=897678view=diff
==
---
[continuum] BUILD SUCCESSFUL: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267471projectId=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=267522projectId=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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to
the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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=897678r1=897677r2=897678view=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,
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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to
the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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=897678r1=897677r2=897678view=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);
+
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 phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it
to the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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=897678r1=897677r2=897678view=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
[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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to
the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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=897678r1=897677r2=897678view=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
Re: [dbcp] multipleThreads test
On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it
to the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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=897678r1=897677r2=897678view=diff
==
---
commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
(original)
+++
Re: [dbcp] multipleThreads test
sebb wrote:
On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it
to the pool. If loopOnce is false,
+ * threads will continue this process indefinitely. If
expectingError is true, exactly 1/2 of the
+ * threads are expected to either throw exceptions or fail to
complete. If expectingError 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:
Re: [dbcp] multipleThreads test
On 10/01/2010, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to the pool. If loopOnce is false, + * threads will continue this process indefinitely. If expectingError is true, exactly 1/2 of the + * threads are expected to either throw exceptions or fail to complete. If expectingError 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
[continuum] BUILD FAILURE: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267564projectId=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
Re: [dbcp] multipleThreads test
sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to the pool. If loopOnce is false, + * threads will continue this process indefinitely. If expectingError is true, exactly 1/2 of the + * threads are expected to either throw exceptions or fail to complete. If expectingError 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
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 phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to the pool. If loopOnce is false, + * threads will continue this process
Re: [dbcp] multipleThreads test
sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 10/01/2010, Phil Steitz phil.ste...@gmail.com 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 phil.ste...@gmail.com 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=897678view=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=897678r1=897677r2=897678view=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 holdTime ms, and then return it to the pool.
Re: [DBCP] Continuum Java 5 build
On 11/01/2010, Phil Steitz phil.ste...@gmail.com 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
[continuum] BUILD FAILURE: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267625projectId=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 luc.maison...@free.fr wrote: Henri Yandell a écrit : On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org 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
