Re: [dbcp] multipleThreads test
Posting the last failed build output while it is, umstill available: Multithread test time = 489 ms. Threads: 20. Loops: 20. Hold time: 200. Maxwait: 100. Done: 11. Did not run: 0. Failed: 9. expectError: true StartupDelay: 0. ConnectTime: 3. Runtime: 203. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 132. Runtime: 333. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 42. ConnectTime: 90. Runtime: 290. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 90. Runtime: 291. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 76. ConnectTime: 14. Runtime: 215. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 13. ConnectTime: 1. Runtime: 202. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 16. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 1. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 11. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 18. ConnectTime: 0. Runtime: 201. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 7. ConnectTime: 17. Runtime: 218. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) There are three things that look odd here. First is that the second successful thread should have failed with a timeout. That may be explainable by wakeup delay. The second is that unless startupDelay is not reliable, the allocation looks unfair and pool 1.5 is supposed to implement fairness - i.e., it should be the threads with lower startupDelays that are served first. This could point to a pool bug. Finally, the connectTimes for some of the successful threads are way too long. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] multipleThreads test
Phil Steitz wrote: Posting the last failed build output while it is, umstill available: Multithread test time = 489 ms. Threads: 20. Loops: 20. Hold time: 200. Maxwait: 100. Done: 11. Did not run: 0. Failed: 9. expectError: true StartupDelay: 0. ConnectTime: 3. Runtime: 203. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 132. Runtime: 333. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 42. ConnectTime: 90. Runtime: 290. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 90. Runtime: 291. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 76. ConnectTime: 14. Runtime: 215. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 13. ConnectTime: 1. Runtime: 202. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 16. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 1. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 11. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 18. ConnectTime: 0. Runtime: 201. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 7. ConnectTime: 17. Runtime: 218. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) There are three things that look odd here. First is that the second successful thread should have failed with a timeout. That may be explainable by wakeup delay. The second is that unless startupDelay is not reliable, the allocation looks unfair and pool 1.5 is supposed to implement fairness - i.e., it should be the threads with lower startupDelays that are served first. Scratch that. pooledConnectionAndInfo has a synch block before the call to borrowObject to create or acquire the pool. All threads are going after the same pool. The first one in has to create the pool. Phil This could point to a pool bug. Finally, the connectTimes for some of the successful threads are way too long. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] multipleThreads test
On 11/01/2010, Phil Steitz phil.ste...@gmail.com wrote: Phil Steitz wrote: Posting the last failed build output while it is, umstill available: I assume this is from: http://vmbuild.apache.org/continuum/buildResult.action?buildId=267625projectId=22 Multithread test time = 489 ms. Threads: 20. Loops: 20. Hold time: 200. Maxwait: 100. Done: 11. Did not run: 0. Failed: 9. expectError: true StartupDelay: 0. ConnectTime: 3. Runtime: 203. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 132. Runtime: 333. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 42. ConnectTime: 90. Runtime: 290. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: 90. Runtime: 291. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 76. ConnectTime: 14. Runtime: 215. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 13. ConnectTime: 1. Runtime: 202. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 16. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 1. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 11. ConnectTime: 0. Runtime: 200. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 18. ConnectTime: 0. Runtime: 201. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 7. ConnectTime: 17. Runtime: 218. Loops: 1. State: Done. thrown: null. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 101. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 1. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) StartupDelay: 0. ConnectTime: -. Runtime: 100. Loops: 1. State: Getting Connection. thrown: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool. (using nanoTime) There are three things that look odd here. First is that the second successful thread should have failed with a timeout. That may be explainable by wakeup delay. The second is that unless startupDelay is not reliable, the allocation looks unfair and pool 1.5 is supposed to implement fairness - i.e., it should be the threads with lower startupDelays that are served first. Scratch that. pooledConnectionAndInfo has a synch block before the call to borrowObject to create or acquire the pool. All threads are going after the same pool. The first one in has to create the pool. It's rather odd. The successful threads all took 200+ms to complete, during which time there should be no spare connections available. Yet the second thread only appears to have waited 132ms to get the connection. [Which should have caused a timeout error, but perhaps that's excusable.] However, it should not be possible to aquire the 11th connection in less than 200ms. What happened to that thread? Did it somehow stall before waiting for the connection? If so, why is the overall runtime for the thread only 333ms? I will add some more info to the debug output. Phil This could point to a pool bug. Finally, the connectTimes for some of the successful threads are way too long. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:
[continuum] BUILD SUCCESSFUL: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=267969projectId=22 Build statistics: State: Ok Previous State: Failed Started at: Mon 11 Jan 2010 09:31:04 -0800 Finished at: Mon 11 Jan 2010 09:32:29 -0800 Total time: 1m 25s Build Trigger: Schedule Build Number: 135 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: Changed: sebb @ Mon 11 Jan 2010 07:26:42 -0800 Comment: More debug for Continuum fail Files changed: /commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/TestConnectionPool.java ( 897906 ) 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: 50.237995 - 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
Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. The [lang] maths package is fo non-mathematicians. The [math] library is for serious mathematicians. Big difference. As per the commons charter, there is nothing wrong with having duplicated code/concepts in Commons. Stephen Paul Benedict wrote: 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 - 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
On Mon, Jan 11, 2010 at 5:17 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. Having people to import Commons Math to just use Fraction is equal to people having to import Commons Lang to use Fraction. If that's all you want, you have to import something. Likewise, since I don't think this class is missing from the JDK, I don't think it deserves to stay in Commons Lang. It doesn't add to anything in the Java language -- it is the foundation of a math library. Paul - 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
-- it is the foundation of a math library. I have to disagree on this point. An application can use Fractions instead of a doubles, if you can deal with the API usage compared to operators. This what we (in a different century, when I worked for a Smalltalk vendor) did in Smalltalk for ALL non-integers, we used fractions and precision was never lost. Neat trick when supported at the language level. In a similar vein, I've lost count as to how many times, I've re-invented Smalltalk's Association class. Now that Java has Generics, I think I've finally settled on something reusable. So I do not see Fraction as the foundation for anything really. It stands on its own nicely IMO. Gary -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Monday, January 11, 2010 15:25 To: Commons Developers List Subject: Re: [lang] Divesting the commons.lang.math package On Mon, Jan 11, 2010 at 5:17 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. Having people to import Commons Math to just use Fraction is equal to people having to import Commons Lang to use Fraction. If that's all you want, you have to import something. Likewise, since I don't think this class is missing from the JDK, I don't think it deserves to stay in Commons Lang. It doesn't add to anything in the Java language -- it is the foundation of a math library. Paul - 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 - Java 5 - default ant buildDefinition
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=268145projectId=2624 Build statistics: State: Failed Previous Build: No previous build. Started at: Mon 11 Jan 2010 17:30:17 -0800 Finished at: Mon 11 Jan 2010 17:30:36 -0800 Total time: 18s Build Trigger: Schedule Build Number: 0 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 : Apache Ant version 1.7.0 compiled on December 13 2006 Dependencies Changes: No dependencies changed Build Definition: Ant build filename: build.xml Goals: $build.buildDefinition.goals Arguments: $build.buildDefinition.arguments Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Description: default ant buildDefinition Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
