Re: [VOTE] Release Commons IO 2.0.1 based on RC1

[Phil Steitz]

On Wed, Dec 22, 2010 at 11:15 PM, Niall Pemberton  wrote:

> There have been a couple of bugs fixed since the IO 2.0 release, so I
> would like to release IO 2.0.1
>
> [X ] +1 Yes go ahead an release based on RC1
> [ ] -1 No, because...
>
> IO 2.0.1 RC1 is available for review here:
>  
> http://people.apache.org/~niallp/io-2.01.-rc1/
>

Should be http://people.apache.org/~niallp/io-2.0.1-rc1/

>
> Maven artifacts are here:
>  
> http://people.apache.org/~niallp//io-2.0.1-rc1/maven/
>
> Details of changes since 2.0 are in the release notes:
>  
> http://people.apache.org/~niallp/io-2.0.1-rc1/RELEASE-NOTES.txt
>
> NIce format and content of release notes :)


> I have tested this with JDK 1.5 & 1.6 using maven2.
>
> I tested the Ant and Maven builds on 1.6 only.

Also checked sigs and hashes.

Phil


> The tag is here:
>  http://svn.apache.org/viewvc/commons/proper/io/tags/commons-io-2.0.1-rc1/
>
> Site:
>  
> http://people.apache.org/~niallp/io-2.0.1-rc1/site/
> (note some *relative* links are broken and the 2.0.1 directories are
> not yet created - these will be OK once the site is deployed)
>
> Clirr Report (compared to 2.0):
>  
> http://people.apache.org/~niallp/io-2.0.1-rc1/site/clirr-report.html
>
> RAT Report:
>  
> http://people.apache.org/~niallp/io-2.0.1-rc1/site/rat-report.html
>
> tia
>
> Niall
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[pool] GKOP clearOldest behavior

[Phil Steitz]

I notice now that in the doco cleanup before pool 1.5, we left one more
inscrutable "feature" of GKOP undocumented, namely the behavior determined
by the clearOldest method added in pool 1.3.   This (non-optional) feature
destroys 15% of the "oldest" idle instances in the union of the pools to
"make room" when a borrowObject attempt bumps up against maxTotal and there
are idle instances (with other keys) that could be sacrificed.  This
behavior makes sense for the DBCP use case (prepared statement pools), but
may not always be desirable.  I think it should be configurable (whether or
not to do it and possibly the trimming %) and documented.   The 1.5 changes
to take factory methods out of synch blocks also increase the activation
rate of clearOldest, since the internal processing count is included in the
guard.  It might actually be better to eliminate that from a performance
perspective (i.e. only activate when _totalActive + _totalIdle >=
_maxTotal).

This feature was implemented in POOL-49.  Prior versions just invoked
clear() to eliminate all idle instances when maxTotal was attained.

Phil

Re: [pool][performance] Source management question

[Phil Steitz]

Thanks, Gary!

On Sat, Dec 25, 2010 at 9:11 AM, Gary Gregory
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" 
> 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"  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
>
>

Re: [math] Random Generator from Stable Distribution

[Pavel Ryzhov]

So, I've created jira MATH-462 for it and attached the patch.
It doesn't contain tests for alpha in (0,1) yet. I'll take a look at R examples 
and will try to generate quantiles for some alpha.

On Dec 24, 2010, at 19:07 PM, Phil Steitz wrote:

> On Fri, Dec 24, 2010 at 10:13 AM, Pavel Ryzhov wrote:
> 
>> Hi,
>> 
>> I've implemented a Stable random generator based on Chambers-Mallows-Stuck
>> method as it is described in "Handbook of computational statistics: concepts
>> and methods" by James E. Gentle, Wolfgang Härdle, Yuichi Mori
>> 
> 
> Thanks!  Looks good after quick review.
> 
>> 
>> But I'm stuck on unit-testing of the generator as I don't have estimators
>> of stable distribution parameters. I cannot use moments to
>> approve/disapprove if the sample satisfies to the distribution
>> 
>> Thus I've to fall back to tests with known moments:
>> 1. Normal distribution (alpha = 2 and beta=0.0)
>> 2. Cauchy distribution (alpha = 1 and beta=0.0)
>> 3. Alpha > 1
>> The alpha interval (0, 1) stays untested.
>> 
>> The questions are:
>> 1. Is it worth to include it into Commons Math?
>> 
> 
> Yes.
> 
> 
>> 2. Are these unit-tests enough for acceptance?
>> 
> 
> What I try to do in these cases is find another implementation to compare
> against of reference data somewhere.  I have not checked yet, but most
> likely R has this distribution.  The reference data for most of the other
> distribution comes from R.  Obviously, these tests are not definitive; but
> agreement with R is a good indication that the implementation is correct.
> Have a look in src/test/R.  See, for example, TDistributionTestCases.R.
> 
> Phil
> 
>> 
>> Pavel
>> -
>> 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: [pool][performance] Source management question

[Gary Gregory]

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

Re: [pool][performance] Source management question

[Gary Gregory]

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