Re: [configuration] Dependencies after switch to 1.4
I believe this could be addressed by changing the pom to only include Xerces and XML-APIs when compiling with JDK 5+ with a desired target of JDK 5+ and then having the unit tests that use validation only run when Java 5+ is enabled. However, this seems like a lot of work for little benefit since Xerces and XML-APIs already have test scope so they won't be brought in to a user's project unless they wants them. Ralph On Jan 2, 2010, at 12:22 PM, Oliver Heger wrote: > In order to change the minimum required JDK to 1.4 I modified pom.xml. I was > hoping to get rid of all the XML-related dependencies, but obviously this is > not so easy. > > When dropping the Xerces-dependency I get a bunch of test failures: > - Many of them are caused by tests for DatabaseConfiguration. Here dbunit > cannot resolve the DTD in the dataset file. This can be solved by simply > removing the reference to the DTD. > - The major problem is caused by tests that require advanced validation > features, e.g. schema validation. This is not supported by the parser shipped > with Java 1.4. > > Because of the latter point I think we are forced to keep the > Xerces-dependency (with test scope). Unfortunately, this also demands the > dependency to XML-APIs - otherwise I get NoClassDefFound errors. > > Or is there an alternative? > > At least the dependency to Xalan can be dropped. I wonder whether this has > some impact on GUMP which has still trouble with building [configuration]. > > Oliver > > - > 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
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
Re: [configuration] Dependencies after switch to 1.4
Henri Yandell schrieb: What would a dependency of 1.5 mean with regards to the Xerces dependency? You depend on Lang/Collections, and both are 1.5 dependent for their next version. With 1.5 the Xerces dependency is no more needed. There is some work going on for a Configuration 2.0 version which uses Java 1.5. We have a branch for this project. So the idea is that 2.0 depends on Java 1.5 while the 1.x series remains on 1.4. Once 2.0 is released, there should only be bug-fix releases for 1.x. However, I fear there is still much work to do before 2.0 can be published. Oliver Hen On Sat, Jan 2, 2010 at 12:22 PM, Oliver Heger wrote: In order to change the minimum required JDK to 1.4 I modified pom.xml. I was hoping to get rid of all the XML-related dependencies, but obviously this is not so easy. When dropping the Xerces-dependency I get a bunch of test failures: - Many of them are caused by tests for DatabaseConfiguration. Here dbunit cannot resolve the DTD in the dataset file. This can be solved by simply removing the reference to the DTD. - The major problem is caused by tests that require advanced validation features, e.g. schema validation. This is not supported by the parser shipped with Java 1.4. Because of the latter point I think we are forced to keep the Xerces-dependency (with test scope). Unfortunately, this also demands the dependency to XML-APIs - otherwise I get NoClassDefFound errors. Or is there an alternative? At least the dependency to Xalan can be dropped. I wonder whether this has some impact on GUMP which has still trouble with building [configuration]. Oliver - 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: [configuration] Dependencies after switch to 1.4
Ralph Goers schrieb: I believe this could be addressed by changing the pom to only include Xerces and XML-APIs when compiling with JDK 5+ with a desired target of JDK 5+ and then having the unit tests that use validation only run when Java 5+ is enabled. However, this seems like a lot of work for little benefit since Xerces and XML-APIs already have test scope so they won't be brought in to a user's project unless they wants them. Ralph Agreed, it is probably not worth the effort. So it is a matter of documentation on our dependencies page. There has to be a statement that Xerces is required on JDK 1.4 for schema validation. Oliver On Jan 2, 2010, at 12:22 PM, Oliver Heger wrote: In order to change the minimum required JDK to 1.4 I modified pom.xml. I was hoping to get rid of all the XML-related dependencies, but obviously this is not so easy. When dropping the Xerces-dependency I get a bunch of test failures: - Many of them are caused by tests for DatabaseConfiguration. Here dbunit cannot resolve the DTD in the dataset file. This can be solved by simply removing the reference to the DTD. - The major problem is caused by tests that require advanced validation features, e.g. schema validation. This is not supported by the parser shipped with Java 1.4. Because of the latter point I think we are forced to keep the Xerces-dependency (with test scope). Unfortunately, this also demands the dependency to XML-APIs - otherwise I get NoClassDefFound errors. Or is there an alternative? At least the dependency to Xalan can be dropped. I wonder whether this has some impact on GUMP which has still trouble with building [configuration]. Oliver - 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][collections] Overlap; Collections thoughts
On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote: On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz wrote: Henri Yandell wrote: I was thinking more that a smaller [collections] might have room for the functor code again - not that [lang] would :) Agreed that it's better out than in though. That is instructive, but sort of hurts the case, though, as functors are arguably closer to a language extension than they are related to the [collections] domain. Agreed that it's a bad example. I'd used it as a component that had left collections for some reason and might be a better fit - not from a technical perspective. My negative to adding to Lang would be that unlike the Enum and NestedException pieces of code, functional-in-OO needs a lot of language support to feel good. Better examples of what might be peeled off into [lang] could be the iterators or decorators. Can you get a little more specific on what parts of [collections] you see as in scope for merging into [lang]? https://issues.apache.org/jira/browse/LANG-532 has a bit. The various XxxUtils classes - but not the factory builder parts that supply various aspects. A slice of the iterators and the comparators. Possibly some basic 'missing' implementations such as ArrayStack, ArraySet, FastVector etc. So its the bits that connect the domain to the JDK? That would put, for example, parts of o.a.c.math.stat.StatUtils, o.a.c.math.util.MathUtils similarly in scope. The question here is what is special about [collections] and doesn't this just amount to artificially hacking off pieces that belong with the domain? I am still not seeing the "joints" here. Lang's math.NumberUtils and math.Fraction for example. MathUtils and a little bit of StatUtils do look to be similar in scope. The special bits with collections are: * Lang issues are identifying overlap problems with Collections. ArrayUtils starts to look like Collections when you take a more generic approach to a problem (for example ArraySet), ComparableComparator was recently copied over (private class) and there is a ComparableUtils class request. * I have concerns over whether there will be a Collections 4.0. My view on this is "eventually"--I certainly feel I've put in too much work to simply let [collections] go. However, the following issue you identified has been a thorn in my side for quite some time so I am on board for streamlining, multiple artifacts, and anything else that will improve the situation. * Collections has issues that say (paraphrasing) "Nice idea, don't commit until Collections is lighter in weight". * Collections has more code at the JDK level being hidden by more additional features than say IO (less additional features), Codec (not a lot of JDK level code), Math (not a lot of JDK level code). Like [collections], they all have a more specialized domain that is their primary focus. So the natural question is, if this makes sense for [collections], why not everywhere else? Answering that question might help clarify intent here. Yup. We've already been doing it with BeanUtils - some of the code moved/copied over in 3.0. What it would possibly mean in your commons wide suggestion is a bunch of components having a dependency on [lang], which as you say below has often been a blocker. Then again - all java.* code depends on java.lang.* :) Can you explain a little more what exactly has moved from BeanUtils and what kinds of other things you have in mind? I thought the new reflect package was from BeanUtils. I think by way of the reflect sandbox component. If not code from BeanUtils, it is a direct overlap with some of the code at the core of BeanUtils. That code was indeed cloned/copied from BeanUtils. The [reflect] component in the sandbox didn't figure into the pedigree, though some of the class names there would understandably suggest otherwise (or, for all I know [reflect] may have also been cloned from BeanUtils code). The point being that oacl.reflect provides a thin veneer over java.lang.reflect and thus seemed to be a proper fit. -Matt One final comment is that a logical alternative is to just split [collections] internally into multiple pieces with separate release cycles. Managing dependencies among the subcomponents and user documentation might be tricky. IIRC, that is what has prevented us from actually ever doing this up to now. Yup. Effectively this is both a split into 'Collections JDK' and 'Collections Structures', and a merge of Collections JDK to Lang. A natural question to ask is is that the best way to split [collections] up? It would probably force some users to depend on - and look for stuff in - [lang] when [collections] by itself would now meet their needs. Pulling the iterators, for example, out of [collections] would make it harder to use by itself and I bet would force [collections] itself to depend on [lang]. I am not (yet) convinced that this is the best way to divide [colle
[continuum] BUILD SUCCESSFUL: Commons - Commons Configuration -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=265195&projectId=161 Build statistics: State: Ok Previous State: Failed Started at: Fri 1 Jan 2010 14:47:15 -0800 Finished at: Fri 1 Jan 2010 14:51:20 -0800 Total time: 4m 4s Build Trigger: Schedule Build Number: 151 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: no author @ no date Comment: no comment Files changed: xdocs/dependencies.xml ( no revision ) xdocs/building.xml ( no revision ) pom.xml ( no revision ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 1456 Failures: 0 Errors: 0 Success Rate: 100 Total time: 144.61998 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang][collections] Overlap; Collections thoughts
Paul Benedict wrote: > Each if you split Collections into Maven children, you would still > wouldn't want to release them independently. That would be a gigantic > administrative error. Struts was thinking about doing the same thing > with its libraries, but we turned away from it -- THANKFULLY. How > would you explain to users what versions are compatible with each > other? It becomes a nightmare to manage. That is a very good point. It would only be possible to separate the release cycles if you could somehow guarantee that mixing and matching subcomponent versions would *always* work, which is probably impractical. I think your later suggestion is a better way to go - keep doing bundled releases, but do them more often. Phil > > 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
[g...@vmgump]: Project commons-vfs (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-vfs has an issue affecting its community integration. This issue affects 44 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-contrib : Useful little Ant tasks - ant-contrib-test : Useful little Ant tasks - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - cddlm : Configuration and Deployment of Grid Applications and System... - commons-configuration : Apache Commons - commons-configuration-test : Apache Commons - commons-jelly-tags-ojb : Commons Jelly - commons-vfs : Apache Commons - commons-vfs-sandbox : Apache Commons - commons-vfs-test : Apache Commons - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. - excalibur-xmlutil-test : Repository of reusable components. - forrest-rat : Apache Forrest is an XML standards-oriented documentation fr... - fulcrum-configuration-impl : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - invicta : Open-source build management tool. - ivy : Ivy Core - ivy-tests : Ivy is a tool for managing (recording, tracking, resolving a... - jakarta-turbine-jcs : Cache - logging-log4cxx-ant : Apache log4cxx - logging-log4cxx-ant-no_wchar_t : Apache log4cxx - logging-log4cxx-ant-static : Apache log4cxx - org.apache.commons:commons-vfs : Apache Commons - smartfrog : Smartfrog: Application Deployment from HP Laboratories - smartfrog-components : Smartfrog: Application Deployment from HP Laboratories - smartfrog-tasks : Smartfrog: Application Deployment from HP Laboratories - smartfrog-tasks-test : Smartfrog: Application Deployment from HP Laboratories - smartfrog-test : Smartfrog: Application Deployment from HP Laboratories - smartfrog-testharness : Smartfrog: Application Deployment from HP Laboratories - test-ojb : ObjectRelationalBridge Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-vfs-2.0-SNAPSHOT.jar] identifier set to project name -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/gump_work/build_apache-commons_commons-vfs.html Work Name: build_apache-commons_commons-vfs (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: mvn --batch-mode -Dmaven.test.skip.exec=true --settings /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/vfs] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/junit/dist/junit-01012010.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-01012010.jar:/sr
[continuum] BUILD SUCCESSFUL: Commons - Commons VFS -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=265231&projectId=171 Build statistics: State: Ok Previous State: Failed Started at: Fri 1 Jan 2010 17:35:09 -0800 Finished at: Fri 1 Jan 2010 17:39:23 -0800 Total time: 4m 14s Build Trigger: Schedule Build Number: 43 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: no author @ no date Comment: no comment Files changed: pom.xml ( no revision ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 977 Failures: 0 Errors: 0 Success Rate: 100 Total time: 108.22099 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: RESULT: Failed [VOTE] Release DBCP 1.3/1.4 - take three
On 03/01/2010, Phil Steitz wrote: > sebb wrote: > > On 03/01/2010, sebb wrote: > >> On 02/01/2010, Phil Steitz wrote: > >> > sebb wrote: > >> > > On 01/01/2010, Phil Steitz wrote: > >> > >> Phil Steitz wrote: > >> > >> > sebb wrote: > >> > >> >> On 31/12/2009, Phil Steitz wrote: > >> > >> >>> Comments have not changed sebb's -1, so I am going to > consider this > >> > >> >>> a failed VOTE and roll another RC with documentation fixes > already > >> > >> >>> made included and attempt at clearer release notes and > README. > >> > >> >>> > >> > >> >>> Thanks, all for review and sorry to take so long to get this > right. > >> > >> >> Please note that I am still seeing the occasional test > failures (even > >> > >> >> after the test bug fix). > >> > >> >> As a result, I did not revisit the -1 for the compilation > problems - > >> > >> >> the test failure seems like a -1 to me as well. > >> > >> > > >> > >> > In that case, I am honestly inclined to just remove / disable > the > >> > >> > tests. As I said before, they are fragile and frankly > half-baked. > >> > >> > Unfortunately, they did uncover a real bug recently, so I am of > two > >> > >> > minds on this. > >> > >> > > >> > >> > What is going on in the most recent failure you reported (line > 376 > >> > >> > of TestPerUserPoolDataSource) is a ThreadGroup is started > launching > >> > >> > 2 * maxActive threads, all of which try to get connections, hold > >> > >> > them for (sic) 1 ms and then release them. MaxWait is 100 ms > and > >> > >> > maxActive is 10. This "should" work as the effective > throughput > >> > >> > should be ~10 requests / ms (that assumes perfect efficiency > and no > >> > >> > execution time, which is not quite right), so 20 requests should > >> > >> > complete in ~20 ms. > >> > >> > >> > >> > >> > >> Sorry - that should be 2 ms. > >> > > > >> > > If maxWait is 100ms, and each thread waits 1ms, surely this should > always work? > >> > > Even if each wait actually takes 50ms, the first 10 requests will > take > >> > > approx 50ms, and the remaining 10 requests will then get their > >> > > connections. > >> > > > >> > > In the tests I ran last year (!), at least some of the failed tests > >> > > showed that 10 of the threads timed out, i.e. none of the original > 10 > >> > > threads had finished. It seems a bit unlikely that this is really an > >> > > issue with the processing times. > >> > > > >> > > I think this needs closer investigation - I'll try and add some more > >> > > debug for the failed cases. > >> > > >> > > >> > Thanks. I just completed 1000 runs each using Apple 1.5, 1.6, Sun > >> > 1.6 and JRockit 1.4 (last two on Ubuntu 9.10) with no failures. > >> > >> > >> Any tests using multiple core systems? > >> > >> > >> > You are correct that with maxActive = 10, throughput should be > >> > nearly 10/ms, so 20 should finish in 2ms. There are three things > >> > that can dampen the throughput: > >> > > >> > 1) Elapsed time between when a thread invokes sleep(1) and performs > >> > its next action (which is to return the connection it is holding) > >> > 2) Elapsed time waiting for a waiting thread to respond to notify > >> > 3) There is a trivial amount of code executed by the threads holding > >> > the connections and of course the pool itself executes some code. > >> > > >> > What JDK are you using when you see these failures? > >> > >> > >> java version "1.6.0_17" > >> Java(TM) SE Runtime Environment (build 1.6.0_17-b04) > >> Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) > >> > >> This is on Windows XP, dual-processor (Centrino). > >> > >> There is another bug in the test - it does not wait for all the > >> threads to finish. > >> However, I don't think this affects the result, as the first test is > >> the one that fails, so there can't be any threads at that point. > >> However it could affect the second test, as the same driver and pool > >> is used. The two tests should probably be separate test cases. > >> > > > > When a test fails for me, 10 threads get timeouts. > > All the first 10 threads take longer than 100ms to complete and all > > take about the same amount of time (within 5ms or so). > > > There should be 20 threads launched by the test that does not expect > timeouts. So 10 are completing in time and 10 are timing out? 10 complete without any failures, however they all take over 100ms to complete - e.g. 160ms or 200ms - and so the other 10 threads suffer timeouts. > > > > This does not seem to be due to cpu starvation, because the timeouts > > occur some while before the first 10 threads complete. This suggests > > to me that the JVM is not being stalled by garbage collection or > > external activities. > > > I doubt it is either
Re: RESULT: Failed [VOTE] Release DBCP 1.3/1.4 - take three
sebb wrote: > On 03/01/2010, Phil Steitz wrote: >> sebb wrote: >> > On 03/01/2010, sebb wrote: >> >> On 02/01/2010, Phil Steitz wrote: >> >> > sebb wrote: >> >> > > On 01/01/2010, Phil Steitz wrote: >> >> > >> Phil Steitz wrote: >> >> > >> > sebb wrote: >> >> > >> >> On 31/12/2009, Phil Steitz wrote: >> >> > >> >>> Comments have not changed sebb's -1, so I am going to >> consider this >> >> > >> >>> a failed VOTE and roll another RC with documentation fixes >> already >> >> > >> >>> made included and attempt at clearer release notes and >> README. >> >> > >> >>> >> >> > >> >>> Thanks, all for review and sorry to take so long to get >> this right. >> >> > >> >> Please note that I am still seeing the occasional test >> failures (even >> >> > >> >> after the test bug fix). >> >> > >> >> As a result, I did not revisit the -1 for the compilation >> problems - >> >> > >> >> the test failure seems like a -1 to me as well. >> >> > >> > >> >> > >> > In that case, I am honestly inclined to just remove / disable >> the >> >> > >> > tests. As I said before, they are fragile and frankly >> half-baked. >> >> > >> > Unfortunately, they did uncover a real bug recently, so I am >> of two >> >> > >> > minds on this. >> >> > >> > >> >> > >> > What is going on in the most recent failure you reported (line >> 376 >> >> > >> > of TestPerUserPoolDataSource) is a ThreadGroup is started >> launching >> >> > >> > 2 * maxActive threads, all of which try to get connections, >> hold >> >> > >> > them for (sic) 1 ms and then release them. MaxWait is 100 ms >> and >> >> > >> > maxActive is 10. This "should" work as the effective >> throughput >> >> > >> > should be ~10 requests / ms (that assumes perfect efficiency >> and no >> >> > >> > execution time, which is not quite right), so 20 requests >> should >> >> > >> > complete in ~20 ms. >> >> > >> >> >> > >> >> >> > >> Sorry - that should be 2 ms. >> >> > > >> >> > > If maxWait is 100ms, and each thread waits 1ms, surely this should >> always work? >> >> > > Even if each wait actually takes 50ms, the first 10 requests will >> take >> >> > > approx 50ms, and the remaining 10 requests will then get their >> >> > > connections. >> >> > > >> >> > > In the tests I ran last year (!), at least some of the failed tests >> >> > > showed that 10 of the threads timed out, i.e. none of the original >> 10 >> >> > > threads had finished. It seems a bit unlikely that this is really >> an >> >> > > issue with the processing times. >> >> > > >> >> > > I think this needs closer investigation - I'll try and add some >> more >> >> > > debug for the failed cases. >> >> > >> >> > >> >> > Thanks. I just completed 1000 runs each using Apple 1.5, 1.6, Sun >> >> > 1.6 and JRockit 1.4 (last two on Ubuntu 9.10) with no failures. >> >> >> >> >> >> Any tests using multiple core systems? >> >> >> >> >> >> > You are correct that with maxActive = 10, throughput should be >> >> > nearly 10/ms, so 20 should finish in 2ms. There are three things >> >> > that can dampen the throughput: >> >> > >> >> > 1) Elapsed time between when a thread invokes sleep(1) and performs >> >> > its next action (which is to return the connection it is holding) >> >> > 2) Elapsed time waiting for a waiting thread to respond to notify >> >> > 3) There is a trivial amount of code executed by the threads holding >> >> > the connections and of course the pool itself executes some code. >> >> > >> >> > What JDK are you using when you see these failures? >> >> >> >> >> >> java version "1.6.0_17" >> >> Java(TM) SE Runtime Environment (build 1.6.0_17-b04) >> >> Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) >> >> >> >> This is on Windows XP, dual-processor (Centrino). >> >> >> >> There is another bug in the test - it does not wait for all the >> >> threads to finish. >> >> However, I don't think this affects the result, as the first test is >> >> the one that fails, so there can't be any threads at that point. >> >> However it could affect the second test, as the same driver and pool >> >> is used. The two tests should probably be separate test cases. >> >> >> > >> > When a test fails for me, 10 threads get timeouts. >> > All the first 10 threads take longer than 100ms to complete and all >> > take about the same amount of time (within 5ms or so). >> >> >> There should be 20 threads launched by the test that does not expect >> timeouts. So 10 are completing in time and 10 are timing out? > > 10 complete without any failures, however they all take over 100ms to > complete - e.g. 160ms or 200ms - and so the other 10 threads suffer > timeouts. > > >> > This does not seem to be due to cpu starvation, because the timeouts >> > occur some while before the first 10 threads
