On 25/12/2010 16:18, Phil Steitz wrote: > Thanks, Gary! > > On Sat, Dec 25, 2010 at 9:11 AM, Gary Gregory > <ggreg...@seagullsoftware.com>wrote: > > Hm. Perfo already depends on pool. It would be less controversial to add the >> test to perfo but that would not demonstrate the bug in pool itself. >> > > I thought about that. That would amount to attaching a [performance] > config file to a [pool] JIRA ticket. That would demonstrate the bug, but > without a unit test in [pool] itself, we would have no way to ensure that it > did not resurface. Also, since [performance] is not released, the config is > likely to continue to change. > > think I would still depend on perfo. >> >> But [performance] is a sandbox component that has not been - and may never > be - released, so this ends up as us a snapshot dependency, which I would > like to avoid.
Sorry for coming to this late - I have been away for New Year. The test - in what ever form - really needs to be in pool to ensure we don't introduce a regression. Here is a thought, what about an svn external? It can be pinned to HEAD or a specific version. However, I'd be hapy with any of the other solutions you suggested as well. Mark > > Phil > > > >> Gary >> >> On Dec 25, 2010, at 9:03, "Gary Gregory" <ggreg...@seagullsoftware.com> >> wrote: >> >>> I would just have this new test depend on [performance] and be done with >> it. >>> >>> Gary >>> >>> On Dec 25, 2010, at 0:53, "Phil Steitz" <phil.ste...@gmail.com> wrote: >>> >>>> I have found what I think is a bug in GKOP[1] using [performance]. I >> need >>>> the functionality in the Waiter and WaiterFactory classes in >>>> o.a.c.performance.pool to build a test case showing the bug. Having >> these >>>> classes available to pool's unit tests would be good. I am not sure >> what >>>> the best approach is to make these classes available to the [pool] tests >> and >>>> would appreciate some advice. I could just copy them, but I don't like >> the >>>> idea of maintaining both versions. Even if [performance] was a proper >>>> component and had a release, I don't much like the idea of adding a >>>> dependency. I could move them to [pool]'s test package, but then >>>> [performance] could not access them unless [pool] were to export a test >>>> jar. Any ideas? Thanks in advance. >>>> >>>> Phil >>>> >>>> [1] For those waiting with baited breath to learn what the bug is, it >>>> manifests as maxActivePerKey exceeded by one. This can happen when idle >>>> instances retrieved from the pool fail validation and destroy has >>>> non-trivial latency. The problem is (I think) the result of clearOldest >> not >>>> updating the per-key internal processing counts. >>> >>> --------------------------------------------------------------------- >>> 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
