On Mon, Jan 3, 2011 at 10:17 AM, Mark Thomas <ma...@apache.org> wrote:
> 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. > > Thanks. Thought of that too, but I don't like externals :) I am going to go ahead and just add classes with the needed functionality to the [pool] test tree. Its not a large amount of code and the [performance] classes can be stripped down a little. Phil > 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 > >
