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 think I would still depend on perfo.
Gary On Dec 25, 2010, at 9:03, "Gary Gregory" <[email protected]> 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" <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
