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. 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 > >
