Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

In Nexus, I see
https://repository.apache.org/content/repositories/orgapachecommons-1396
owned by struberg. Where are we on this?

Gary

On Fri, Nov 23, 2018 at 4:58 AM Mark Struberg 
wrote:

> To clarify why this change was done:
> This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool which caused an efective shutdown of all the server by
> staling the pool in various cases.
>
> This solved my problem. I created test to make sure to not introduce new
> ones. But the code is way too much organically grown to be 100% sure. it
> probably need a clean rewrite.
> I had another solution which created too many pooled instances. My hope
> was that the create() method will prevent exactly that! If this doesn't
> work.
> Yes, we need to have a null-check on the return param of create and deal
> with that case. But if we still get too many idle objects, then create() is
> broken as well, isn't?
>
> LieGrue,
> strub
>
>
>
> > Am 19.11.2018 um 23:34 schrieb Gary Gregory :
> >
> >
> > diff --git
> > a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > index 0575f7e..6d81dbc 100644
> > --- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > +++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> > @@ -920,8 +920,7 @@
> > // In case there are already threads waiting on something in
> > the pool
> > // (e.g. idleObjects.takeFirst(); then we need to provide
> them
> > a fresh instance.
> > // Otherwise they will be stuck forever (or until timeout)
> > -PooledObject freshPooled = create();
> > -idleObjects.put(freshPooled);
> > +addObject();
> > }
> > }
> >
> > But causes a failure:
> >
> > [INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
> > [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 12.253 s <<< FAILURE! - in
> > org.apache.commons.pool2.impl.TestAbandonedObjectPool
> > [ERROR]
> >
> testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
> > Time elapsed: 3.668 s  <<< FAILURE!
> > java.lang.AssertionError: expected:<5> but was:<4>
> >at
> >
> org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
> >
> > Maybe this is due to my busy CPU, not sure.
> >
> > Gary
> >
> >
> >>
> >> Phil
> >>
> >> On 11/19/18 2:31 PM, Gary Gregory wrote:
> >>> A unit test? Yes please! :-)
> >>>
> >>> Gary
> >>>
> >>> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg
>  >>>
> >>> wrote:
> >>>
>  +1 for the null check.
> 
>  Do you want to re-open the ticket and create a patch?
> 
>  I've created a unit test which proves my original problem with the
>  dead-lock.
>  So any improvement should be rather on the safe side from here on.
> 
> 
>  Regarding the RC: this is really not needed anymore when working with
> >> GIT
>  as nothing gets pushed/released to the main repository! See the config
>  changes I did to the maven-release-plugin.
> 
>  txs and LieGrue,
>  strub
> 
> 
> 
> > Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> >
> > On 11/19/18 8:19 AM, Gary Gregory wrote:
> >> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
>  wrote:
> >>> I’d be happy to roll the release if we get master to where you want
>  it.
> >> IMO, we should integrate the recent PR I mentioned and roll RC3.
> Note
>  that this vote subject thread did not contain an RC number. Sticking
> to
> >> the
>  usual process would be less troublesome IMO.
> > I have not had a chance to fully review and am not really active in
>  [pool] any more, but I did notice that the fix for POOL-356 is
> missing a
>  null check between these two added statements:
> >  PooledObject freshPooled = create();
> > idleObjects.put(freshPooled);
> >
> > create() can return null and while in general it won't in this
>  activation context, given the lack of sync control, it is possible
> that
> >> a
>  return hits between the if test and execution resulting in no capacity
> >> to
>  create.
> > I also notice some system.outs made it into the test code in one of
> the
>  commits related to POOL-340.
> > Phil
> >> Gary
> >>
> >>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Nov 19, 2018, at 7:18 AM, Mark Struberg
> >>  >>> wrote:
>  Oki, I now see what you mean.
> 
>  We actually have 3 source zips now.
> 
>  .src.zip
>  .source-release.zip
>  src.jar
> 
>  That's a mess.
> 
>  There should only be 2:
>  * source-release.zip is the official ASF packages whole build
> >> sources.
> >>> This includes the pom, build structure etc.
> 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

> On Nov 28, 2018, at 9:06 AM, Mark Struberg  wrote:
> 
> Yes, not destroying the borrowed object would be an option. I didn't want to 
> go down that route as there are multiple reasons why a borrowed object is not 
> valid anymore.
> E.g. it could be 'consumed', it could be broken, shouldn't be used do to 
> maxUsageTime is over, etc. 

Those are good things to worry about but the change I suggested below preserves 
all of the checks associated with validation and instance state.  All it does 
is effectively recode maxIdle to 1 when it is set to 0 and there are take 
waiters.

Phil

> That's why I opted for calling create(). But of course, that has other 
> potential issues :/
> 
> LieGrue,
> strub
> 
> 
>> Am 28.11.2018 um 04:21 schrieb Phil Steitz :
>> 
>> On 11/26/18 1:23 PM, Phil Steitz wrote:
 On 11/26/18 8:29 AM, Phil Steitz wrote:
> On 11/26/18 6:19 AM, Mark Struberg wrote:
> Hi Phil!
 
 Let me start by repeating that other than trying to help diagnose bugs and 
 answer user questions, I don't really work on [pool] any more, so I don't 
 really have any standing here.  You are the RM, so it is completely up to 
 you and the active Commons committers to decide what to do with the code.  
 So fine to ignore my comments.
> 
> 
>>  I think that the right answer here is WONT_FIX. That sounds harsh, but 
>> it seems to me
>> that the obvious solution here is for the user to set maxIdle to at 
>> least 1.
> I thought about that as well!
> Setting maxIdle to 1 will make it less likely but a deadlock will STILL 
> happen.
 I am not sure this is right.  If maxIdle >0, the fix for POOL-240 (a 
 similar liveness issue) should kick in and work. Each time a validation or 
 passivation failure occurs on return, there is a call to ensureIdle that 
 will create a new instance and add it to the pool if there is capacity to 
 do so.
> So I fear we really need to tackle this. Stackoverflow and our own bug 
> tracker is full of such reports :(
 
 I see one additional actual report on GKOP (the other linked issue, which 
 should be similarly patched if the consensus is to do this for GOP). The 
 vast majority of the liveness reports that we have gotten over the years 
 in DBCP and pool are just pool exhausted due to failure to return 
 instances.
 
 The workaround violating maxIdle will restore liveness, but is likely the 
 wrong solution here.  Again, up to you guys to judge. Note that when you 
 specify maxIdle equal to 1
>>> Crap.  Meant 0 there.
 you are telling the pool to destroy all returning instances.  To use the 
 pool in this way is silly, IMO.  With your patch, new instances are still 
 created for *every* borrow.  The pool and all of its machinery is doing 
 nothing other than tracking the number of active instances and making sure 
 life cycle events are fired.  If you want the semantics of returning 
 object with threads waiting to be that the returning object is passivated, 
 activated and handed directly to a waiter without every hitting the idle 
 instance pool, that would require rewriting a fair bit of the borrow / 
 return code.  It is an interesting idea and would solve the POOL-240 as 
 well.
 
 One final comment.  If you stick with something like what is in the code 
 now, you should make sure to passivate the new instance before putting it 
 into the pool.  I just noticed that ensureIdle does not do that, which I 
 think is a bug in that method.  So if you want to proceed with this fix, I 
 would recommend
 
 1.  Move the ensureIdle activations added in POOL-240 into destroy itself.
 2.  Add passivation to ensureIdle
 3.  Implement corresponding workaround for GKOP
>> 
>> Sorry, all.  Looking again and thinking a little more, I think the best fix 
>> for this is actually to prevent the destroy on return in the first place if 
>> there are take waiters.  The maxIdle invariant gets violated with the 
>> ensureIdle or direct create() fix anyway and just allowing the returning 
>> instance to go into the pool avoids the needless destroy / create sequence.  
>> A simple way to do this is just to recode maxIdle before the destroy test in 
>> returnObject.
>> Instead of
>> 
>> final int maxIdleSave = getMaxIdle()
>> explicitly recode it:
>> 
>> // If maxIdle is set to 0 and there are take waiters, bump it to 1
>> // to preserve liveness.
>> final int maxIdleSave = idleObjects.hasTakeWaiters() ? 
>> Math.max(1,getMaxIdle()) : getMaxIdle();
>> 
>> Phil
>> 
 
 Phil
 
 
> LieGrue,
> strub
> 
> 
>> Am 23.11.2018 um 16:51 schrieb Phil Steitz:
>> 
>> On 11/23/18 2:57 AM, Mark Struberg wrote:
>>> should read: This change (putting a new item back to the idle pool) was 
>>> needed to prevent a dead-lock
>>> 
>>> *grabbing a 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Yes, not destroying the borrowed object would be an option. I didn't want to go 
down that route as there are multiple reasons why a borrowed object is not 
valid anymore.
E.g. it could be 'consumed', it could be broken, shouldn't be used do to 
maxUsageTime is over, etc. 
That's why I opted for calling create(). But of course, that has other 
potential issues :/

LieGrue,
strub


> Am 28.11.2018 um 04:21 schrieb Phil Steitz :
> 
> On 11/26/18 1:23 PM, Phil Steitz wrote:
>> On 11/26/18 8:29 AM, Phil Steitz wrote:
>>> On 11/26/18 6:19 AM, Mark Struberg wrote:
 Hi Phil!
>>> 
>>> Let me start by repeating that other than trying to help diagnose bugs and 
>>> answer user questions, I don't really work on [pool] any more, so I don't 
>>> really have any standing here.  You are the RM, so it is completely up to 
>>> you and the active Commons committers to decide what to do with the code.  
>>> So fine to ignore my comments.
 
 
>   I think that the right answer here is WONT_FIX. That sounds harsh, but 
> it seems to me
> that the obvious solution here is for the user to set maxIdle to at least 
> 1.
 I thought about that as well!
 Setting maxIdle to 1 will make it less likely but a deadlock will STILL 
 happen.
>>> I am not sure this is right.  If maxIdle >0, the fix for POOL-240 (a 
>>> similar liveness issue) should kick in and work. Each time a validation or 
>>> passivation failure occurs on return, there is a call to ensureIdle that 
>>> will create a new instance and add it to the pool if there is capacity to 
>>> do so.
 So I fear we really need to tackle this. Stackoverflow and our own bug 
 tracker is full of such reports :(
>>> 
>>> I see one additional actual report on GKOP (the other linked issue, which 
>>> should be similarly patched if the consensus is to do this for GOP). The 
>>> vast majority of the liveness reports that we have gotten over the years in 
>>> DBCP and pool are just pool exhausted due to failure to return instances.
>>> 
>>> The workaround violating maxIdle will restore liveness, but is likely the 
>>> wrong solution here.  Again, up to you guys to judge. Note that when you 
>>> specify maxIdle equal to 1
>> Crap.  Meant 0 there.
>>> you are telling the pool to destroy all returning instances.  To use the 
>>> pool in this way is silly, IMO.  With your patch, new instances are still 
>>> created for *every* borrow.  The pool and all of its machinery is doing 
>>> nothing other than tracking the number of active instances and making sure 
>>> life cycle events are fired.  If you want the semantics of returning object 
>>> with threads waiting to be that the returning object is passivated, 
>>> activated and handed directly to a waiter without every hitting the idle 
>>> instance pool, that would require rewriting a fair bit of the borrow / 
>>> return code.  It is an interesting idea and would solve the POOL-240 as 
>>> well.
>>> 
>>> One final comment.  If you stick with something like what is in the code 
>>> now, you should make sure to passivate the new instance before putting it 
>>> into the pool.  I just noticed that ensureIdle does not do that, which I 
>>> think is a bug in that method.  So if you want to proceed with this fix, I 
>>> would recommend
>>> 
>>> 1.  Move the ensureIdle activations added in POOL-240 into destroy itself.
>>> 2.  Add passivation to ensureIdle
>>> 3.  Implement corresponding workaround for GKOP
> 
> Sorry, all.  Looking again and thinking a little more, I think the best fix 
> for this is actually to prevent the destroy on return in the first place if 
> there are take waiters.  The maxIdle invariant gets violated with the 
> ensureIdle or direct create() fix anyway and just allowing the returning 
> instance to go into the pool avoids the needless destroy / create sequence.  
> A simple way to do this is just to recode maxIdle before the destroy test in 
> returnObject.
> Instead of
> 
> final int maxIdleSave = getMaxIdle()
> explicitly recode it:
> 
> // If maxIdle is set to 0 and there are take waiters, bump it to 1
> // to preserve liveness.
>  final int maxIdleSave = idleObjects.hasTakeWaiters() ? 
> Math.max(1,getMaxIdle()) : getMaxIdle();
> 
> Phil
> 
>>> 
>>> Phil
>>> 
>>> 
 LieGrue,
 strub
 
 
> Am 23.11.2018 um 16:51 schrieb Phil Steitz:
> 
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was 
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee* le
> I am sorry I did not look carefully enough at this issue before reviewing 
> the change.  After reviewing the DBCP ticket (OP likely unrelated, IMO), 
> I think that the right answer here is WONT_FIX. That sounds harsh, but it 
> seems to me that the obvious solution here is for the user to set maxIdle 
> to at least 1.  What the fix does is effectively that, without changing 
> the setting.  

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/26/18 1:23 PM, Phil Steitz wrote:

On 11/26/18 8:29 AM, Phil Steitz wrote:

On 11/26/18 6:19 AM, Mark Struberg wrote:

Hi Phil!


Let me start by repeating that other than trying to help diagnose 
bugs and answer user questions, I don't really work on [pool] any 
more, so I don't really have any standing here.  You are the RM, 
so it is completely up to you and the active Commons committers 
to decide what to do with the code.  So fine to ignore my comments.



  I think that the right answer here is WONT_FIX. That sounds 
harsh, but it seems to me
that the obvious solution here is for the user to set maxIdle 
to at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock 
will STILL happen.
I am not sure this is right.  If maxIdle >0, the fix for POOL-240 
(a similar liveness issue) should kick in and work. Each time a 
validation or passivation failure occurs on return, there is a 
call to ensureIdle that will create a new instance and add it to 
the pool if there is capacity to do so.
So I fear we really need to tackle this. Stackoverflow and our 
own bug tracker is full of such reports :(


I see one additional actual report on GKOP (the other linked 
issue, which should be similarly patched if the consensus is to 
do this for GOP). The vast majority of the liveness reports that 
we have gotten over the years in DBCP and pool are just pool 
exhausted due to failure to return instances.


The workaround violating maxIdle will restore liveness, but is 
likely the wrong solution here.  Again, up to you guys to judge. 
Note that when you specify maxIdle equal to 1

Crap.  Meant 0 there.
you are telling the pool to destroy all returning instances.  To 
use the pool in this way is silly, IMO.  With your patch, new 
instances are still created for *every* borrow.  The pool and all 
of its machinery is doing nothing other than tracking the number 
of active instances and making sure life cycle events are fired.  
If you want the semantics of returning object with threads 
waiting to be that the returning object is passivated, activated 
and handed directly to a waiter without every hitting the idle 
instance pool, that would require rewriting a fair bit of the 
borrow / return code.  It is an interesting idea and would solve 
the POOL-240 as well.


One final comment.  If you stick with something like what is in 
the code now, you should make sure to passivate the new instance 
before putting it into the pool.  I just noticed that ensureIdle 
does not do that, which I think is a bug in that method.  So if 
you want to proceed with this fix, I would recommend


1.  Move the ensureIdle activations added in POOL-240 into 
destroy itself.

2.  Add passivation to ensureIdle
3.  Implement corresponding workaround for GKOP


Sorry, all.  Looking again and thinking a little more, I think the 
best fix for this is actually to prevent the destroy on return in 
the first place if there are take waiters.  The maxIdle invariant 
gets violated with the ensureIdle or direct create() fix anyway and 
just allowing the returning instance to go into the pool avoids the 
needless destroy / create sequence.  A simple way to do this is just 
to recode maxIdle before the destroy test in returnObject.

Instead of

final int maxIdleSave = getMaxIdle()
explicitly recode it:

// If maxIdle is set to 0 and there are take waiters, bump it to 1
// to preserve liveness.
 final int maxIdleSave = idleObjects.hasTakeWaiters() ? 
Math.max(1,getMaxIdle()) : getMaxIdle();


Phil



Phil



LieGrue,
strub



Am 23.11.2018 um 16:51 schrieb Phil Steitz:

On 11/23/18 2:57 AM, Mark Struberg wrote:
should read: This change (putting a new item back to the idle 
pool) was needed to prevent a dead-lock


*grabbing a fresh coffee* le
I am sorry I did not look carefully enough at this issue before 
reviewing the change.  After reviewing the DBCP ticket (OP 
likely unrelated, IMO), I think that the right answer here is 
WONT_FIX. That sounds harsh, but it seems to me that the 
obvious solution here is for the user to set maxIdle to at 
least 1.  What the fix does is effectively that, without 
changing the setting.  If waiting threads die or time out while 
the create is happening, there will be an idle instance in the 
pool and for certain one is being put there on the way to 
getting checked back out.  See comments on POOL-327.


If the consensus is to insert this workaround to enable the 
pool to retain liveness in the use case, it's probably best to 
use ensureIdle(1, false) (see POOL-240).  It could be that just 
moving the call to ensureIdle inside destroy would be OK.  But 
as stated above, this breaks the maxIdle contract.


I see that your original report / use case here is from DBCP, 
Mark.  Was it prepared statements or connections that you were 
trying to limit to 0 idle?  Is there a reason that just using 1 
would not work?


Phil



Am 23.11.2018 um 10:49 schrieb Mark Struberg:

This change 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/26/18 8:29 AM, Phil Steitz wrote:

On 11/26/18 6:19 AM, Mark Struberg wrote:

Hi Phil!


Let me start by repeating that other than trying to help diagnose 
bugs and answer user questions, I don't really work on [pool] any 
more, so I don't really have any standing here.  You are the RM, 
so it is completely up to you and the active Commons committers to 
decide what to do with the code.  So fine to ignore my comments.



  I think that the right answer here is WONT_FIX. That sounds 
harsh, but it seems to me
that the obvious solution here is for the user to set maxIdle to 
at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will 
STILL happen.
I am not sure this is right.  If maxIdle >0, the fix for POOL-240 
(a similar liveness issue) should kick in and work.  Each time a 
validation or passivation failure occurs on return, there is a 
call to ensureIdle that will create a new instance and add it to 
the pool if there is capacity to do so.
So I fear we really need to tackle this. Stackoverflow and our 
own bug tracker is full of such reports :(


I see one additional actual report on GKOP (the other linked 
issue, which should be similarly patched if the consensus is to do 
this for GOP). The vast majority of the liveness reports that we 
have gotten over the years in DBCP and pool are just pool 
exhausted due to failure to return instances.


The workaround violating maxIdle will restore liveness, but is 
likely the wrong solution here.  Again, up to you guys to judge. 
Note that when you specify maxIdle equal to 1

Crap.  Meant 0 there.
you are telling the pool to destroy all returning instances.  To 
use the pool in this way is silly, IMO.  With your patch, new 
instances are still created for *every* borrow.  The pool and all 
of its machinery is doing nothing other than tracking the number 
of active instances and making sure life cycle events are fired.  
If you want the semantics of returning object with threads waiting 
to be that the returning object is passivated, activated and 
handed directly to a waiter without every hitting the idle 
instance pool, that would require rewriting a fair bit of the 
borrow / return code.  It is an interesting idea and would solve 
the POOL-240 as well.


One final comment.  If you stick with something like what is in 
the code now, you should make sure to passivate the new instance 
before putting it into the pool.  I just noticed that ensureIdle 
does not do that, which I think is a bug in that method.  So if 
you want to proceed with this fix, I would recommend


1.  Move the ensureIdle activations added in POOL-240 into destroy 
itself.

2.  Add passivation to ensureIdle
3.  Implement corresponding workaround for GKOP

Phil



LieGrue,
strub



Am 23.11.2018 um 16:51 schrieb Phil Steitz:

On 11/23/18 2:57 AM, Mark Struberg wrote:
should read: This change (putting a new item back to the idle 
pool) was needed to prevent a dead-lock


*grabbing a fresh coffee* le
I am sorry I did not look carefully enough at this issue before 
reviewing the change.  After reviewing the DBCP ticket (OP 
likely unrelated, IMO), I think that the right answer here is 
WONT_FIX. That sounds harsh, but it seems to me that the obvious 
solution here is for the user to set maxIdle to at least 1.  
What the fix does is effectively that, without changing the 
setting.  If waiting threads die or time out while the create is 
happening, there will be an idle instance in the pool and for 
certain one is being put there on the way to getting checked 
back out.  See comments on POOL-327.


If the consensus is to insert this workaround to enable the pool 
to retain liveness in the use case, it's probably best to use 
ensureIdle(1, false) (see POOL-240).  It could be that just 
moving the call to ensureIdle inside destroy would be OK.  But 
as stated above, this breaks the maxIdle contract.


I see that your original report / use case here is from DBCP, 
Mark.  Was it prepared statements or connections that you were 
trying to limit to 0 idle?  Is there a reason that just using 1 
would not work?


Phil



Am 23.11.2018 um 10:49 schrieb Mark Struberg:

This change (putting a new item back to the idle pool was 
needed to prevent a dead-pool


- 


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







-
To unsubscribe, e-mail: 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/26/18 8:29 AM, Phil Steitz wrote:

On 11/26/18 6:19 AM, Mark Struberg wrote:

Hi Phil!


Let me start by repeating that other than trying to help diagnose 
bugs and answer user questions, I don't really work on [pool] any 
more, so I don't really have any standing here.  You are the RM, 
so it is completely up to you and the active Commons committers to 
decide what to do with the code.  So fine to ignore my comments.



  I think that the right answer here is WONT_FIX. That sounds 
harsh, but it seems to me
that the obvious solution here is for the user to set maxIdle to 
at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will 
STILL happen.
I am not sure this is right.  If maxIdle >0, the fix for POOL-240 
(a similar liveness issue) should kick in and work.  Each time a 
validation or passivation failure occurs on return, there is a 
call to ensureIdle that will create a new instance and add it to 
the pool if there is capacity to do so.
So I fear we really need to tackle this. Stackoverflow and our 
own bug tracker is full of such reports :(


I see one additional actual report on GKOP (the other linked 
issue, which should be similarly patched if the consensus is to do 
this for GOP). The vast majority of the liveness reports that we 
have gotten over the years in DBCP and pool are just pool 
exhausted due to failure to return instances.


The workaround violating maxIdle will restore liveness, but is 
likely the wrong solution here.  Again, up to you guys to judge. 
Note that when you specify maxIdle equal to 1 you are telling the 
pool to destroy all returning instances.  To use the pool in this 
way is silly, IMO.  With your patch, new instances are still 
created for *every* borrow.  The pool and all of its machinery is 
doing nothing other than tracking the number of active instances 
and making sure life cycle events are fired.  If you want the 
semantics of returning object with threads waiting to be that the 
returning object is passivated, activated and handed directly to a 
waiter without every hitting the idle instance pool, that would 
require rewriting a fair bit of the borrow / return code.  It is 
an interesting idea and would solve the POOL-240 as well.


One final comment.  If you stick with something like what is in 
the code now, you should make sure to passivate the new instance 
before putting it into the pool.  I just noticed that ensureIdle 
does not do that, which I think is a bug in that method.  So if 
you want to proceed with this fix, I would recommend


1.  Move the ensureIdle activations added in POOL-240 into destroy 
itself.

2.  Add passivation to ensureIdle


Sorry, looks to me like this is not actually necessary.  So I take 
back my comment that this is a bug in ensureIdle.



3. Implement corresponding workaround for GKOP

Phil



LieGrue,
strub



Am 23.11.2018 um 16:51 schrieb Phil Steitz:

On 11/23/18 2:57 AM, Mark Struberg wrote:
should read: This change (putting a new item back to the idle 
pool) was needed to prevent a dead-lock


*grabbing a fresh coffee* le
I am sorry I did not look carefully enough at this issue before 
reviewing the change.  After reviewing the DBCP ticket (OP 
likely unrelated, IMO), I think that the right answer here is 
WONT_FIX. That sounds harsh, but it seems to me that the obvious 
solution here is for the user to set maxIdle to at least 1.  
What the fix does is effectively that, without changing the 
setting.  If waiting threads die or time out while the create is 
happening, there will be an idle instance in the pool and for 
certain one is being put there on the way to getting checked 
back out.  See comments on POOL-327.


If the consensus is to insert this workaround to enable the pool 
to retain liveness in the use case, it's probably best to use 
ensureIdle(1, false) (see POOL-240).  It could be that just 
moving the call to ensureIdle inside destroy would be OK.  But 
as stated above, this breaks the maxIdle contract.


I see that your original report / use case here is from DBCP, 
Mark.  Was it prepared statements or connections that you were 
trying to limit to 0 idle?  Is there a reason that just using 1 
would not work?


Phil



Am 23.11.2018 um 10:49 schrieb Mark Struberg:

This change (putting a new item back to the idle pool was 
needed to prevent a dead-pool


- 


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/26/18 6:19 AM, Mark Struberg wrote:

Hi Phil!


Let me start by repeating that other than trying to help diagnose 
bugs and answer user questions, I don't really work on [pool] any 
more, so I don't really have any standing here.  You are the RM, so 
it is completely up to you and the active Commons committers to 
decide what to do with the code.  So fine to ignore my comments.




  I think that the right answer here is WONT_FIX. That sounds harsh, but it 
seems to me
that the obvious solution here is for the user to set maxIdle to at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.
I am not sure this is right.  If maxIdle >0, the fix for POOL-240 (a 
similar liveness issue) should kick in and work.  Each time a 
validation or passivation failure occurs on return, there is a call 
to ensureIdle that will create a new instance and add it to the pool 
if there is capacity to do so.

So I fear we really need to tackle this. Stackoverflow and our own bug tracker 
is full of such reports :(


I see one additional actual report on GKOP (the other linked issue, 
which should be similarly patched if the consensus is to do this for 
GOP). The vast majority of the liveness reports that we have gotten 
over the years in DBCP and pool are just pool exhausted due to 
failure to return instances.


The workaround violating maxIdle will restore liveness, but is 
likely the wrong solution here.  Again, up to you guys to judge. 
Note that when you specify maxIdle equal to 1 you are telling the 
pool to destroy all returning instances.  To use the pool in this 
way is silly, IMO.  With your patch, new instances are still created 
for *every* borrow.  The pool and all of its machinery is doing 
nothing other than tracking the number of active instances and 
making sure life cycle events are fired.  If you want the semantics 
of returning object with threads waiting to be that the returning 
object is passivated, activated and handed directly to a waiter 
without every hitting the idle instance pool, that would require 
rewriting a fair bit of the borrow / return code.  It is an 
interesting idea and would solve the POOL-240 as well.


One final comment.  If you stick with something like what is in the 
code now, you should make sure to passivate the new instance before 
putting it into the pool.  I just noticed that ensureIdle does not 
do that, which I think is a bug in that method.  So if you want to 
proceed with this fix, I would recommend


1.  Move the ensureIdle activations added in POOL-240 into destroy 
itself.

2.  Add passivation to ensureIdle
3.  Implement corresponding workaround for GKOP

Phil



LieGrue,
strub



Am 23.11.2018 um 16:51 schrieb Phil Steitz:

On 11/23/18 2:57 AM, Mark Struberg wrote:

should read: This change (putting a new item back to the idle pool) was needed 
to prevent a dead-lock

*grabbing a fresh coffee* le

I am sorry I did not look carefully enough at this issue before reviewing the 
change.  After reviewing the DBCP ticket (OP likely unrelated, IMO), I think 
that the right answer here is WONT_FIX. That sounds harsh, but it seems to me 
that the obvious solution here is for the user to set maxIdle to at least 1.  
What the fix does is effectively that, without changing the setting.  If 
waiting threads die or time out while the create is happening, there will be an 
idle instance in the pool and for certain one is being put there on the way to 
getting checked back out.  See comments on POOL-327.

If the consensus is to insert this workaround to enable the pool to retain 
liveness in the use case, it's probably best to use ensureIdle(1, false) (see 
POOL-240).  It could be that just moving the call to ensureIdle inside destroy 
would be OK.  But as stated above, this breaks the maxIdle contract.

I see that your original report / use case here is from DBCP, Mark.  Was it 
prepared statements or connections that you were trying to limit to 0 idle?  Is 
there a reason that just using 1 would not work?

Phil



Am 23.11.2018 um 10:49 schrieb Mark Struberg:

This change (putting a new item back to the idle pool was needed to prevent a 
dead-pool

-
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





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

I think we still need to address what happens if null gets returned in create().
This was something I missed.
Not sure if it got addressed in the meantime?

LieGrue,
strub


> Am 26.11.2018 um 14:26 schrieb Rob Tompkins :
> 
> 
> 
>> On Nov 26, 2018, at 8:16 AM, Mark Struberg  wrote:
>> 
>> Hi Gary!
>> 
>> I've added multi-line comments in the middle of code blocks I touched.
>> e.g. 
>> https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
>> 
>> I also tried to write extensive commit comments.
> 
> Sounds good. I’ll try to get to starting the release today. 
> 
> -Rob
> 
>> 
>> LieGrue,
>> strub
>> 
>>> Am 23.11.2018 um 16:18 schrieb Gary Gregory :
>>> 
>>> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
>>> wrote:
>>> 
 should read: This change (putting a new item back to the idle pool) was
 needed to prevent a dead-lock
 
 *grabbing a fresh coffee*
 
> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
> 
> This change (putting a new item back to the idle pool was needed to
 prevent a dead-pool
 
>>> 
>>> Hi Mark,
>>> 
>>> Would you mind adding some comments to the code to help future maintainers?
>>> 
>>> Gary (currently sipping coffee)
>>> 
>>> 
 
 
 -
 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


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Rob Tompkins]

> On Nov 26, 2018, at 8:16 AM, Mark Struberg  wrote:
> 
> Hi Gary!
> 
> I've added multi-line comments in the middle of code blocks I touched.
> e.g. 
> https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
> 
> I also tried to write extensive commit comments.

Sounds good. I’ll try to get to starting the release today. 

-Rob

> 
> LieGrue,
> strub
> 
>> Am 23.11.2018 um 16:18 schrieb Gary Gregory :
>> 
>> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
>> wrote:
>> 
>>> should read: This change (putting a new item back to the idle pool) was
>>> needed to prevent a dead-lock
>>> 
>>> *grabbing a fresh coffee*
>>> 
 Am 23.11.2018 um 10:49 schrieb Mark Struberg :
 
 This change (putting a new item back to the idle pool was needed to
>>> prevent a dead-pool
>>> 
>> 
>> Hi Mark,
>> 
>> Would you mind adding some comments to the code to help future maintainers?
>> 
>> Gary (currently sipping coffee)
>> 
>> 
>>> 
>>> 
>>> -
>>> 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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Hi Phil!


>  I think that the right answer here is WONT_FIX. That sounds harsh, but it 
> seems to me
> that the obvious solution here is for the user to set maxIdle to at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.

So I fear we really need to tackle this. Stackoverflow and our own bug tracker 
is full of such reports :(

LieGrue,
strub


> Am 23.11.2018 um 16:51 schrieb Phil Steitz :
> 
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was 
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee* le
> 
> I am sorry I did not look carefully enough at this issue before reviewing the 
> change.  After reviewing the DBCP ticket (OP likely unrelated, IMO), I think 
> that the right answer here is WONT_FIX. That sounds harsh, but it seems to me 
> that the obvious solution here is for the user to set maxIdle to at least 1.  
> What the fix does is effectively that, without changing the setting.  If 
> waiting threads die or time out while the create is happening, there will be 
> an idle instance in the pool and for certain one is being put there on the 
> way to getting checked back out.  See comments on POOL-327.
> 
> If the consensus is to insert this workaround to enable the pool to retain 
> liveness in the use case, it's probably best to use ensureIdle(1, false) (see 
> POOL-240).  It could be that just moving the call to ensureIdle inside 
> destroy would be OK.  But as stated above, this breaks the maxIdle contract.
> 
> I see that your original report / use case here is from DBCP, Mark.  Was it 
> prepared statements or connections that you were trying to limit to 0 idle?  
> Is there a reason that just using 1 would not work?
> 
> Phil
> 
> 
>> 
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>> 
>>> This change (putting a new item back to the idle pool was needed to prevent 
>>> a dead-pool
>>> 
>>> -
>>> 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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Hi Gary!

I've added multi-line comments in the middle of code blocks I touched.
e.g. 
https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919

I also tried to write extensive commit comments.

LieGrue,
strub

> Am 23.11.2018 um 16:18 schrieb Gary Gregory :
> 
> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
> wrote:
> 
>> should read: This change (putting a new item back to the idle pool) was
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee*
>> 
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>> 
>>> This change (putting a new item back to the idle pool was needed to
>> prevent a dead-pool
>> 
> 
> Hi Mark,
> 
> Would you mind adding some comments to the code to help future maintainers?
> 
> Gary (currently sipping coffee)
> 
> 
>> 
>> 
>> -
>> 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: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Fri, Nov 23, 2018 at 11:51 AM Rob Tompkins  wrote:

>
>
> > On Nov 23, 2018, at 10:51 AM, Phil Steitz  wrote:
> >
> > On 11/23/18 2:57 AM, Mark Struberg wrote:
> >> should read: This change (putting a new item back to the idle pool) was
> needed to prevent a dead-lock
> >>
> >> *grabbing a fresh coffee* le
> >
> > I am sorry I did not look carefully enough at this issue before
> reviewing the change.  After reviewing the DBCP ticket (OP likely
> unrelated, IMO), I think that the right answer here is WONT_FIX. That
> sounds harsh, but it seems to me that the obvious solution here is for the
> user to set maxIdle to at least 1.  What the fix does is effectively that,
> without changing the setting.  If waiting threads die or time out while the
> create is happening, there will be an idle instance in the pool and for
> certain one is being put there on the way to getting checked back out.  See
> comments on POOL-327.
> >
> > If the consensus is to insert this workaround to enable the pool to
> retain liveness in the use case, it's probably best to use ensureIdle(1,
> false) (see POOL-240).  It could be that just moving the call to ensureIdle
> inside destroy would be OK.  But as stated above, this breaks the maxIdle
> contract.
> >
> > I see that your original report / use case here is from DBCP, Mark.  Was
> it prepared statements or connections that you were trying to limit to 0
> idle?  Is there a reason that just using 1 would not work?
>
> Ok holding off on RC3 then from master. Right?
>

I would think that we at least need to documentation added to the code
someplace to help future maintainers.

Are there code changes coming?

Gary

>
> -Rob
>
> >
> > Phil
> >
> >
> >>
> >>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
> >>>
> >>> This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool
> >>>
> >>> -
> >>> 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
>
>

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Rob Tompkins]

> On Nov 23, 2018, at 10:51 AM, Phil Steitz  wrote:
> 
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was 
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee* le
> 
> I am sorry I did not look carefully enough at this issue before reviewing the 
> change.  After reviewing the DBCP ticket (OP likely unrelated, IMO), I think 
> that the right answer here is WONT_FIX. That sounds harsh, but it seems to me 
> that the obvious solution here is for the user to set maxIdle to at least 1.  
> What the fix does is effectively that, without changing the setting.  If 
> waiting threads die or time out while the create is happening, there will be 
> an idle instance in the pool and for certain one is being put there on the 
> way to getting checked back out.  See comments on POOL-327.
> 
> If the consensus is to insert this workaround to enable the pool to retain 
> liveness in the use case, it's probably best to use ensureIdle(1, false) (see 
> POOL-240).  It could be that just moving the call to ensureIdle inside 
> destroy would be OK.  But as stated above, this breaks the maxIdle contract.
> 
> I see that your original report / use case here is from DBCP, Mark.  Was it 
> prepared statements or connections that you were trying to limit to 0 idle?  
> Is there a reason that just using 1 would not work?

Ok holding off on RC3 then from master. Right?

-Rob

> 
> Phil
> 
> 
>> 
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>> 
>>> This change (putting a new item back to the idle pool was needed to prevent 
>>> a dead-pool
>>> 
>>> -
>>> 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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/23/18 2:57 AM, Mark Struberg wrote:

should read: This change (putting a new item back to the idle pool) was needed 
to prevent a dead-lock

*grabbing a fresh coffee* le


I am sorry I did not look carefully enough at this issue before 
reviewing the change.  After reviewing the DBCP ticket (OP likely 
unrelated, IMO), I think that the right answer here is WONT_FIX. 
That sounds harsh, but it seems to me that the obvious solution here 
is for the user to set maxIdle to at least 1.  What the fix does is 
effectively that, without changing the setting.  If waiting threads 
die or time out while the create is happening, there will be an idle 
instance in the pool and for certain one is being put there on the 
way to getting checked back out.  See comments on POOL-327.


If the consensus is to insert this workaround to enable the pool to 
retain liveness in the use case, it's probably best to use 
ensureIdle(1, false) (see POOL-240).  It could be that just moving 
the call to ensureIdle inside destroy would be OK.  But as stated 
above, this breaks the maxIdle contract.


I see that your original report / use case here is from DBCP, Mark.  
Was it prepared statements or connections that you were trying to 
limit to 0 idle?  Is there a reason that just using 1 would not work?


Phil





Am 23.11.2018 um 10:49 schrieb Mark Struberg :

This change (putting a new item back to the idle pool was needed to prevent a 
dead-pool

-
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: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
wrote:

> should read: This change (putting a new item back to the idle pool) was
> needed to prevent a dead-lock
>
> *grabbing a fresh coffee*
>
> > Am 23.11.2018 um 10:49 schrieb Mark Struberg :
> >
> > This change (putting a new item back to the idle pool was needed to
> prevent a dead-pool
>

Hi Mark,

Would you mind adding some comments to the code to help future maintainers?

Gary (currently sipping coffee)


>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

To clarify why this change was done:
This change (putting a new item back to the idle pool was needed to prevent a 
dead-pool which caused an efective shutdown of all the server by staling the 
pool in various cases.

This solved my problem. I created test to make sure to not introduce new ones. 
But the code is way too much organically grown to be 100% sure. it probably 
need a clean rewrite.
I had another solution which created too many pooled instances. My hope was 
that the create() method will prevent exactly that! If this doesn't work.
Yes, we need to have a null-check on the return param of create and deal with 
that case. But if we still get too many idle objects, then create() is broken 
as well, isn't?

LieGrue,
strub



> Am 19.11.2018 um 23:34 schrieb Gary Gregory :
> 
> 
> diff --git
> a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> index 0575f7e..6d81dbc 100644
> --- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> +++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> @@ -920,8 +920,7 @@
> // In case there are already threads waiting on something in
> the pool
> // (e.g. idleObjects.takeFirst(); then we need to provide them
> a fresh instance.
> // Otherwise they will be stuck forever (or until timeout)
> -PooledObject freshPooled = create();
> -idleObjects.put(freshPooled);
> +addObject();
> }
> }
> 
> But causes a failure:
> 
> [INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 12.253 s <<< FAILURE! - in
> org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR]
> testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
> Time elapsed: 3.668 s  <<< FAILURE!
> java.lang.AssertionError: expected:<5> but was:<4>
>at
> org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
> 
> Maybe this is due to my busy CPU, not sure.
> 
> Gary
> 
> 
>> 
>> Phil
>> 
>> On 11/19/18 2:31 PM, Gary Gregory wrote:
>>> A unit test? Yes please! :-)
>>> 
>>> Gary
>>> 
>>> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg >> 
>>> wrote:
>>> 
 +1 for the null check.
 
 Do you want to re-open the ticket and create a patch?
 
 I've created a unit test which proves my original problem with the
 dead-lock.
 So any improvement should be rather on the safe side from here on.
 
 
 Regarding the RC: this is really not needed anymore when working with
>> GIT
 as nothing gets pushed/released to the main repository! See the config
 changes I did to the maven-release-plugin.
 
 txs and LieGrue,
 strub
 
 
 
> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> 
> On 11/19/18 8:19 AM, Gary Gregory wrote:
>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
 wrote:
>>> I’d be happy to roll the release if we get master to where you want
 it.
>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
 that this vote subject thread did not contain an RC number. Sticking to
>> the
 usual process would be less troublesome IMO.
> I have not had a chance to fully review and am not really active in
 [pool] any more, but I did notice that the fix for POOL-356 is missing a
 null check between these two added statements:
>  PooledObject freshPooled = create();
> idleObjects.put(freshPooled);
> 
> create() can return null and while in general it won't in this
 activation context, given the lack of sync control, it is possible that
>> a
 return hits between the if test and execution resulting in no capacity
>> to
 create.
> I also notice some system.outs made it into the test code in one of the
 commits related to POOL-340.
> Phil
>> Gary
>> 
>> 
>>> Cheers,
>>> -Rob
>>> 
 On Nov 19, 2018, at 7:18 AM, Mark Struberg
>> >> wrote:
 Oki, I now see what you mean.
 
 We actually have 3 source zips now.
 
 .src.zip
 .source-release.zip
 src.jar
 
 That's a mess.
 
 There should only be 2:
 * source-release.zip is the official ASF packages whole build
>> sources.
>>> This includes the pom, build structure etc.
 * src.jar is the sources which are automatically downloaded by the
 IDEs
>>> for debugging purpose.
 We have both of them because commons-pool2 is a single-module
>> project.
 And yes, we need both of them. What we do not need is the src.zip. I
>>> have no clue yet where this comes from but it shouldn't be here.
 The good news:
 By leveraging native GIT we now can simply a.) drop the maven
>> 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

should read: This change (putting a new item back to the idle pool) was needed 
to prevent a dead-lock

*grabbing a fresh coffee*

> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
> 
> This change (putting a new item back to the idle pool was needed to prevent a 
> dead-pool


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 2:48 PM Phil Steitz  wrote:

> Sorry ENOTIME, but I remembered that there is a nullsafe
> addIdleObject (see how addObject does it).  In fact, you might just
> replace the manual create and add with just a call to addObject
> itself.  That will also passivate the object before putting it into
> the pool, which is IIRC an invariant (objects put into the idle pool
> are passivated first).
>
> If you want to see the current code blow up, you will have to
> arrange a test with lots of borrows and returns mixed with destroys
> on validate and hope you can get the if test to succeed and then a
> return/borrow sequence before the create.
>

Like this then:

diff --git
a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
index 0575f7e..6d81dbc 100644
--- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
+++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
@@ -920,8 +920,7 @@
 // In case there are already threads waiting on something in
the pool
 // (e.g. idleObjects.takeFirst(); then we need to provide them
a fresh instance.
 // Otherwise they will be stuck forever (or until timeout)
-PooledObject freshPooled = create();
-idleObjects.put(freshPooled);
+addObject();
 }
 }

But causes a failure:

[INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
12.253 s <<< FAILURE! - in
org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR]
testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
Time elapsed: 3.668 s  <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<4>
at
org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)

Maybe this is due to my busy CPU, not sure.

Gary


>
> Phil
>
> On 11/19/18 2:31 PM, Gary Gregory wrote:
> > A unit test? Yes please! :-)
> >
> > Gary
> >
> > On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg  >
> > wrote:
> >
> >> +1 for the null check.
> >>
> >> Do you want to re-open the ticket and create a patch?
> >>
> >> I've created a unit test which proves my original problem with the
> >> dead-lock.
> >> So any improvement should be rather on the safe side from here on.
> >>
> >>
> >> Regarding the RC: this is really not needed anymore when working with
> GIT
> >> as nothing gets pushed/released to the main repository! See the config
> >> changes I did to the maven-release-plugin.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> >>>
> >>> On 11/19/18 8:19 AM, Gary Gregory wrote:
>  On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
> >> wrote:
> > I’d be happy to roll the release if we get master to where you want
> >> it.
>  IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> >> that this vote subject thread did not contain an RC number. Sticking to
> the
> >> usual process would be less troublesome IMO.
> >>> I have not had a chance to fully review and am not really active in
> >> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> >> null check between these two added statements:
> >>>   PooledObject freshPooled = create();
> >>> idleObjects.put(freshPooled);
> >>>
> >>> create() can return null and while in general it won't in this
> >> activation context, given the lack of sync control, it is possible that
> a
> >> return hits between the if test and execution resulting in no capacity
> to
> >> create.
> >>> I also notice some system.outs made it into the test code in one of the
> >> commits related to POOL-340.
> >>> Phil
>  Gary
> 
> 
> > Cheers,
> > -Rob
> >
> >> On Nov 19, 2018, at 7:18 AM, Mark Struberg
>  > wrote:
> >> Oki, I now see what you mean.
> >>
> >> We actually have 3 source zips now.
> >>
> >> .src.zip
> >> .source-release.zip
> >> src.jar
> >>
> >> That's a mess.
> >>
> >> There should only be 2:
> >> * source-release.zip is the official ASF packages whole build
> sources.
> > This includes the pom, build structure etc.
> >> * src.jar is the sources which are automatically downloaded by the
> >> IDEs
> > for debugging purpose.
> >> We have both of them because commons-pool2 is a single-module
> project.
> >> And yes, we need both of them. What we do not need is the src.zip. I
> > have no clue yet where this comes from but it shouldn't be here.
> >> The good news:
> >> By leveraging native GIT we now can simply a.) drop the maven
> stating
> > repo in repository.a.o and b.) drop the release branch and tag from
> my
> > github account and re-roll the release without any weird RC hacks.
> >> Will do that,
> >> * fix the maven 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

Sorry ENOTIME, but I remembered that there is a nullsafe 
addIdleObject (see how addObject does it).  In fact, you might just 
replace the manual create and add with just a call to addObject 
itself.  That will also passivate the object before putting it into 
the pool, which is IIRC an invariant (objects put into the idle pool 
are passivated first).


If you want to see the current code blow up, you will have to 
arrange a test with lots of borrows and returns mixed with destroys 
on validate and hope you can get the if test to succeed and then a 
return/borrow sequence before the create.


Phil

On 11/19/18 2:31 PM, Gary Gregory wrote:

A unit test? Yes please! :-)

Gary

On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg 
wrote:


+1 for the null check.

Do you want to re-open the ticket and create a patch?

I've created a unit test which proves my original problem with the
dead-lock.
So any improvement should be rather on the safe side from here on.


Regarding the RC: this is really not needed anymore when working with GIT
as nothing gets pushed/released to the main repository! See the config
changes I did to the maven-release-plugin.

txs and LieGrue,
strub




Am 19.11.2018 um 16:43 schrieb Phil Steitz :

On 11/19/18 8:19 AM, Gary Gregory wrote:

On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 

wrote:

I’d be happy to roll the release if we get master to where you want

it.

IMO, we should integrate the recent PR I mentioned and roll RC3. Note

that this vote subject thread did not contain an RC number. Sticking to the
usual process would be less troublesome IMO.

I have not had a chance to fully review and am not really active in

[pool] any more, but I did notice that the fix for POOL-356 is missing a
null check between these two added statements:

  PooledObject freshPooled = create();
idleObjects.put(freshPooled);

create() can return null and while in general it won't in this

activation context, given the lack of sync control, it is possible that a
return hits between the if test and execution resulting in no capacity to
create.

I also notice some system.outs made it into the test code in one of the

commits related to POOL-340.

Phil

Gary



Cheers,
-Rob


On Nov 19, 2018, at 7:18 AM, Mark Struberg 
wrote:

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources.

This includes the pom, build structure etc.

* src.jar is the sources which are automatically downloaded by the

IDEs

for debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I

have no clue yet where this comes from but it shouldn't be here.

The good news:
By leveraging native GIT we now can simply a.) drop the maven stating

repo in repository.a.o and b.) drop the release branch and tag from my
github account and re-roll the release without any weird RC hacks.

Will do that,
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub


Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com>:

Le ven. 16 nov. 2018 22:54, Gary Gregory  a

écrit :

On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Le ven. 16 nov. 2018 21:23, Gary Gregory 

a

écrit

:


On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg


wrote:


Oki, now the full VOTE text!

I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.


The ASF staging repository is at


https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/

The sha1 of the source-release zip is
17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is


982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

For me:

$ sha512sum commons-pool2-2.6.1-src.zip



2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e

*commons-pool2-2.6.1-src.zip

Which is not what you list above. Please advise.


Src vs source-release?


That's the problem with inventing a new release process... why do we

have

BOTH:




https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip

AND



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip

And more importantly why are they _different_? Which one will be

used

in

the dist/release area?


Looks like pool didnt do its homework and kept the old assembly

(src),

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

A unit test? Yes please! :-)

Gary

On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg 
wrote:

> +1 for the null check.
>
> Do you want to re-open the ticket and create a patch?
>
> I've created a unit test which proves my original problem with the
> dead-lock.
> So any improvement should be rather on the safe side from here on.
>
>
> Regarding the RC: this is really not needed anymore when working with GIT
> as nothing gets pushed/released to the main repository! See the config
> changes I did to the maven-release-plugin.
>
> txs and LieGrue,
> strub
>
>
>
> > Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> >
> > On 11/19/18 8:19 AM, Gary Gregory wrote:
> >> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
> wrote:
> >>> I’d be happy to roll the release if we get master to where you want
> it.
> >> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> that this vote subject thread did not contain an RC number. Sticking to the
> usual process would be less troublesome IMO.
> >
> > I have not had a chance to fully review and am not really active in
> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> null check between these two added statements:
> >
> >  PooledObject freshPooled = create();
> > idleObjects.put(freshPooled);
> >
> > create() can return null and while in general it won't in this
> activation context, given the lack of sync control, it is possible that a
> return hits between the if test and execution resulting in no capacity to
> create.
> >
> > I also notice some system.outs made it into the test code in one of the
> commits related to POOL-340.
> >
> > Phil
> >>
> >> Gary
> >>
> >>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Nov 19, 2018, at 7:18 AM, Mark Struberg  >
> >>> wrote:
>  Oki, I now see what you mean.
> 
>  We actually have 3 source zips now.
> 
>  .src.zip
>  .source-release.zip
>  src.jar
> 
>  That's a mess.
> 
>  There should only be 2:
>  * source-release.zip is the official ASF packages whole build sources.
> >>> This includes the pom, build structure etc.
>  * src.jar is the sources which are automatically downloaded by the
> IDEs
> >>> for debugging purpose.
>  We have both of them because commons-pool2 is a single-module project.
>  And yes, we need both of them. What we do not need is the src.zip. I
> >>> have no clue yet where this comes from but it shouldn't be here.
> 
>  The good news:
>  By leveraging native GIT we now can simply a.) drop the maven stating
> >>> repo in repository.a.o and b.) drop the release branch and tag from my
> >>> github account and re-roll the release without any weird RC hacks.
>  Will do that,
>  * fix the maven setup
>  * happy to also include the new ticket
>  * re-roll the release this afternoon.
> 
>  LieGrue,
>  strub
> 
> > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>:
> > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> >>> écrit :
> >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le ven. 16 nov. 2018 21:23, Gary Gregory 
> a
> >> écrit
> >>> :
> >>>
>  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>   wrote:
> 
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > The source zip is at
> >
> >
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> >
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>  For me:
> 
>  $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>  *commons-pool2-2.6.1-src.zip
> 
>  Which is not what you list above. Please advise.
> 
> >>> Src vs source-release?
> >>>
> >> That's the problem with inventing a new release process... why do we
> >>> have
> >> BOTH:
> >>
> >>
> >>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >> AND
> >>
> >>
> >>>
> 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

+1 for the null check. 

Do you want to re-open the ticket and create a patch?

I've created a unit test which proves my original problem with the dead-lock. 
So any improvement should be rather on the safe side from here on.


Regarding the RC: this is really not needed anymore when working with GIT as 
nothing gets pushed/released to the main repository! See the config changes I 
did to the maven-release-plugin.

txs and LieGrue,
strub



> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> 
> On 11/19/18 8:19 AM, Gary Gregory wrote:
>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  wrote:
>>> I’d be happy to roll the release if we get master to where you want it. 
>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note that 
>> this vote subject thread did not contain an RC number. Sticking to the usual 
>> process would be less troublesome IMO.
> 
> I have not had a chance to fully review and am not really active in [pool] 
> any more, but I did notice that the fix for POOL-356 is missing a null check 
> between these two added statements:
> 
>  PooledObject freshPooled = create();
> idleObjects.put(freshPooled);
> 
> create() can return null and while in general it won't in this activation 
> context, given the lack of sync control, it is possible that a return hits 
> between the if test and execution resulting in no capacity to create.
> 
> I also notice some system.outs made it into the test code in one of the 
> commits related to POOL-340.
> 
> Phil
>> 
>> Gary
>> 
>> 
>>> Cheers,
>>> -Rob
>>> 
 On Nov 19, 2018, at 7:18 AM, Mark Struberg 
>>> wrote:
 Oki, I now see what you mean.
 
 We actually have 3 source zips now.
 
 .src.zip
 .source-release.zip
 src.jar
 
 That's a mess.
 
 There should only be 2:
 * source-release.zip is the official ASF packages whole build sources.
>>> This includes the pom, build structure etc.
 * src.jar is the sources which are automatically downloaded by the IDEs
>>> for debugging purpose.
 We have both of them because commons-pool2 is a single-module project.
 And yes, we need both of them. What we do not need is the src.zip. I
>>> have no clue yet where this comes from but it shouldn't be here.
 
 The good news:
 By leveraging native GIT we now can simply a.) drop the maven stating
>>> repo in repository.a.o and b.) drop the release branch and tag from my
>>> github account and re-roll the release without any weird RC hacks.
 Will do that,
 * fix the maven setup
 * happy to also include the new ticket
 * re-roll the release this afternoon.
 
 LieGrue,
 strub
 
> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
> Le ven. 16 nov. 2018 22:54, Gary Gregory  a
>>> écrit :
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>> wrote:
>> 
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>> écrit
>>> :
>>> 
 On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> >>> wrote:
 
> Oki, now the full VOTE text!
> 
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
> 
> 
> The ASF staging repository is at
> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> The source zip is at
> 
> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
 For me:
 
 $ sha512sum commons-pool2-2.6.1-src.zip
 
 
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
 *commons-pool2-2.6.1-src.zip
 
 Which is not what you list above. Please advise.
 
>>> Src vs source-release?
>>> 
>> That's the problem with inventing a new release process... why do we
>>> have
>> BOTH:
>> 
>> 
>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>> 
>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>> And more importantly why are they _different_? Which one will be used
>>> in
>> the dist/release area?
>> 
> 
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/19/18 8:19 AM, Gary Gregory wrote:
On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  
wrote:
I’d be happy to roll the release if we get master to where you 
want it. 
IMO, we should integrate the recent PR I mentioned and roll RC3. 
Note that this vote subject thread did not contain an RC number. 
Sticking to the usual process would be less troublesome IMO.


I have not had a chance to fully review and am not really active in 
[pool] any more, but I did notice that the fix for POOL-356 is 
missing a null check between these two added statements:


 PooledObject freshPooled = create();
idleObjects.put(freshPooled);

create() can return null and while in general it won't in this 
activation context, given the lack of sync control, it is possible 
that a return hits between the if test and execution resulting in no 
capacity to create.


I also notice some system.outs made it into the test code in one of 
the commits related to POOL-340.


Phil


Gary



Cheers,
-Rob


On Nov 19, 2018, at 7:18 AM, Mark Struberg 

wrote:

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources.

This includes the pom, build structure etc.

* src.jar is the sources which are automatically downloaded by the IDEs

for debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I

have no clue yet where this comes from but it shouldn't be here.


The good news:
By leveraging native GIT we now can simply a.) drop the maven stating

repo in repository.a.o and b.) drop the release branch and tag from my
github account and re-roll the release without any weird RC hacks.

Will do that,
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub


Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com>:

Le ven. 16 nov. 2018 22:54, Gary Gregory  a

écrit :

On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Le ven. 16 nov. 2018 21:23, Gary Gregory  a

écrit

:


On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg


wrote:


Oki, now the full VOTE text!

I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.


The ASF staging repository is at


https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/

The sha1 of the source-release zip is
17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is


982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

For me:

$ sha512sum commons-pool2-2.6.1-src.zip



2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e

*commons-pool2-2.6.1-src.zip

Which is not what you list above. Please advise.


Src vs source-release?


That's the problem with inventing a new release process... why do we

have

BOTH:




https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip

AND



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip

And more importantly why are they _different_? Which one will be used

in

the dist/release area?



Looks like pool didnt do its homework and kept the old assembly (src),
source-release comes from the parent and is likely the one to keep IMHO



Gary









Gary



I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS

I've created the release in a GIT manner and pushed the according

changes

to my ASF-linked github repo

https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is



https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019

the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171
<

https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171

This will get pushed to the ASF cannonical repo once the VOTE

succeeds.

Site will be updated once the release has passed.

Please VOTE:

[+1] go ship it!
[+0] meh, I don't care
[-1] stop there is a ${showstopper} (that means something

_important_

is

missing!)


Here is my own +1
checked:
* signature
* hashes
* LICENSE
* NOTICE
* rat
* builds fine with various JDKs


LieGrue,
strub






Am 14.11.2018 um 10:13 schrieb Mark Struberg


:

PS: I've created the release in a GIT manner and pushed the

according

changes to my ASF-linked github repo

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  wrote:

> I’d be happy to roll the release if we get master to where you want it.
>

IMO, we should integrate the recent PR I mentioned and roll RC3. Note that
this vote subject thread did not contain an RC number. Sticking to the
usual process would be less troublesome IMO.

Gary


>
> Cheers,
> -Rob
>
> > On Nov 19, 2018, at 7:18 AM, Mark Struberg 
> wrote:
> >
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I
> have no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo in repository.a.o and b.) drop the release branch and tag from my
> github account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> >> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> écrit :
> >>
> >>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >>> wrote:
> >>>
>  Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> >>> écrit
>  :
> 
> > On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>>  >
> > wrote:
> >
> >> Oki, now the full VOTE text!
> >>
> >> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>
> >>
> >> The ASF staging repository is at
> >>
> >
> 
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>
> >> The source zip is at
> >>
> >>
> >
> 
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >> The sha1 of the source-release zip is
> >> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >> The sha512 is
> >>
> >
> 
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>
> >
> > For me:
> >
> > $ sha512sum commons-pool2-2.6.1-src.zip
> >
> >
> 
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > *commons-pool2-2.6.1-src.zip
> >
> > Which is not what you list above. Please advise.
> >
> 
>  Src vs source-release?
> 
> >>>
> >>> That's the problem with inventing a new release process... why do we
> have
> >>> BOTH:
> >>>
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>> AND
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>
> >>> And more importantly why are they _different_? Which one will be used
> in
> >>> the dist/release area?
> >>>
> >>
> >>
> >> Looks like pool didnt do its homework and kept the old assembly (src),
> >> source-release comes from the parent and is likely the one to keep IMHO
> >>
> >>
> >>> Gary
> >>>
> >>>
> >>>
> 
> 
> 
> 
> 
> > Gary
> >
> >
> >>
> >> I added my KEY (struberg at apache.org) to our dist KEYS file
> >> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>
> >> I've created the release in a GIT manner and pushed the according
>  changes
> >> to my ASF-linked github repo
> >>
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >> the sha1 of the commit is
> >>
> >>
> >
> 
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>
> >> the tag is
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >> c910171
> >> <
> >
> >>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >
> >>
> >> This will get pushed to the ASF cannonical repo once the VOTE
> >>> succeeds.
> >>
> >> Site will be updated once the release has passed.
> >>
> >> Please VOTE:
> >>
> >> [+1] go ship it!
> >> [+0] meh, I don't care
> >> [-1] stop there is a ${showstopper} 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Romain Manni-Bucau]

AFAIK source-release is quite standard @asf so likely saner to use that
from now on IMHO.
Agree sources is needed but Think Mark's point was more about assemblies
than default release artifacts.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 nov. 2018 à 15:54, Gary Gregory  a
écrit :

> On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg 
> wrote:
>
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> > This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> > for debugging purpose.
> >
>
> Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
> _should_ contain all sources needed to build the jar and site.
>
> "source-release" is not something we've used here before IIRC.
>
> Gary
>
>
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I have
> > no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo
> > in repository.a.o and b.) drop the release branch and tag from my github
> > account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> > > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> > écrit :
> > >
> > >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> > >> écrit
> > >>> :
> > >>>
> >  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> > >>  > 
> >  wrote:
> > 
> > > Oki, now the full VOTE text!
> > >
> > > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > > The release was run with JDK-1.7 to ensure Java7 compatibility.
> > >
> > >
> > > The ASF staging repository is at
> > >
> > 
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >
> > > The source zip is at
> > >
> > >
> > 
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > The sha512 is
> > >
> > 
> > >>>
> > >>
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >
> > 
> >  For me:
> > 
> >  $ sha512sum commons-pool2-2.6.1-src.zip
> > 
> > 
> > >>>
> > >>
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >  *commons-pool2-2.6.1-src.zip
> > 
> >  Which is not what you list above. Please advise.
> > 
> > >>>
> > >>> Src vs source-release?
> > >>>
> > >>
> > >> That's the problem with inventing a new release process... why do we
> > have
> > >> BOTH:
> > >>
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> > >> AND
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> > >>
> > >> And more importantly why are they _different_? Which one will be used
> in
> > >> the dist/release area?
> > >>
> > >
> > >
> > > Looks like pool didnt do its homework and kept the old assembly (src),
> > > source-release comes from the parent and is likely the one to keep IMHO
> > >
> > >
> > >> Gary
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> >  Gary
> > 
> > 
> > >
> > > I added my KEY (struberg at apache.org) to our dist KEYS file
> > > https://dist.apache.org/repos/dist/release/commons/KEYS
> > >
> > > I've created the release in a GIT manner and pushed the according
> > >>> changes
> > > to my ASF-linked github repo
> > >
> > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > the sha1 of the commit is
> > >
> > >
> > 
> > >>>
> > >>
> >
> 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg 
wrote:

> Oki, I now see what you mean.
>
> We actually have 3 source zips now.
>
> .src.zip
> .source-release.zip
> src.jar
>
> That's a mess.
>
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
>

Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
_should_ contain all sources needed to build the jar and site.

"source-release" is not something we've used here before IIRC.

Gary


>
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have
> no clue yet where this comes from but it shouldn't be here.
>
>
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo
> in repository.a.o and b.) drop the release branch and tag from my github
> account and re-roll the release without any weird RC hacks.
>
> Will do that,
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
>
> LieGrue,
> strub
>
> > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau  >:
> >
> > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> écrit :
> >
> >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> >> écrit
> >>> :
> >>>
>  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>  
>  wrote:
> 
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> 
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >
> > The source zip is at
> >
> >
> 
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> >
> 
> >>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >
> 
>  For me:
> 
>  $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
> >>>
> >>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>  *commons-pool2-2.6.1-src.zip
> 
>  Which is not what you list above. Please advise.
> 
> >>>
> >>> Src vs source-release?
> >>>
> >>
> >> That's the problem with inventing a new release process... why do we
> have
> >> BOTH:
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >> AND
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>
> >> And more importantly why are they _different_? Which one will be used in
> >> the dist/release area?
> >>
> >
> >
> > Looks like pool didnt do its homework and kept the old assembly (src),
> > source-release comes from the parent and is likely the one to keep IMHO
> >
> >
> >> Gary
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
>  Gary
> 
> 
> >
> > I added my KEY (struberg at apache.org) to our dist KEYS file
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > I've created the release in a GIT manner and pushed the according
> >>> changes
> > to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> >
> 
> >>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> > <
> 
> >>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> 
> >
> > This will get pushed to the ASF cannonical repo once the VOTE
> >> succeeds.
> >
> > Site will be updated once the release has passed.
> >
> > Please VOTE:
> >
> > [+1] go ship it!
> > [+0] meh, I don't care
> > [-1] stop there is a ${showstopper} (that means something _important_
> >>> is
> > missing!)
> >
> >
> > Here is my own +1
> > checked:
> > * signature
> > * hashes
> > * LICENSE
> > * NOTICE
> > * rat
> > * builds fine with various JDKs
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> Am 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Rob Tompkins]

I’d be happy to roll the release if we get master to where you want it. 

Cheers,
-Rob

> On Nov 19, 2018, at 7:18 AM, Mark Struberg  wrote:
> 
> Oki, I now see what you mean.
> 
> We actually have 3 source zips now.
> 
> .src.zip
> .source-release.zip
> src.jar
> 
> That's a mess.
> 
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources. This 
> includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs for 
> debugging purpose.
> 
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have no 
> clue yet where this comes from but it shouldn't be here.
> 
> 
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo in 
> repository.a.o and b.) drop the release branch and tag from my github account 
> and re-roll the release without any weird RC hacks.
> 
> Will do that, 
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
> 
> LieGrue,
> strub
> 
>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau :
>> 
>> Le ven. 16 nov. 2018 22:54, Gary Gregory  a écrit :
>> 
>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau 
>>> wrote:
>>> 
 Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>>> écrit
 :
 
> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>  
> wrote:
> 
>> Oki, now the full VOTE text!
>> 
>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>> 
>> 
>> The ASF staging repository is at
>> 
> 
 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>> 
>> The source zip is at
>> 
>> 
> 
 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>> The sha512 is
>> 
> 
 
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>> 
> 
> For me:
> 
> $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
 
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> *commons-pool2-2.6.1-src.zip
> 
> Which is not what you list above. Please advise.
> 
 
 Src vs source-release?
 
>>> 
>>> That's the problem with inventing a new release process... why do we have
>>> BOTH:
>>> 
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>> AND
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>> 
>>> And more importantly why are they _different_? Which one will be used in
>>> the dist/release area?
>>> 
>> 
>> 
>> Looks like pool didnt do its homework and kept the old assembly (src),
>> source-release comes from the parent and is likely the one to keep IMHO
>> 
>> 
>>> Gary
>>> 
>>> 
>>> 
 
 
 
 
 
> Gary
> 
> 
>> 
>> I added my KEY (struberg at apache.org) to our dist KEYS file
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>> 
>> I've created the release in a GIT manner and pushed the according
 changes
>> to my ASF-linked github repo
>> 
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> 
>> 
> 
 
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>> 
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>> <
> 
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> 
>> 
>> This will get pushed to the ASF cannonical repo once the VOTE
>>> succeeds.
>> 
>> Site will be updated once the release has passed.
>> 
>> Please VOTE:
>> 
>> [+1] go ship it!
>> [+0] meh, I don't care
>> [-1] stop there is a ${showstopper} (that means something _important_
 is
>> missing!)
>> 
>> 
>> Here is my own +1
>> checked:
>> * signature
>> * hashes
>> * LICENSE
>> * NOTICE
>> * rat
>> * builds fine with various JDKs
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> 
>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
 >> :
>>> 
>>> PS: I've created the release in a GIT manner and pushed the
>>> according
>> changes to my ASF-linked github repo
>>> 
>>> 

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources. This 
includes the pom, build structure etc.
* src.jar is the sources which are automatically downloaded by the IDEs for 
debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I have no 
clue yet where this comes from but it shouldn't be here.


The good news:
By leveraging native GIT we now can simply a.) drop the maven stating repo in 
repository.a.o and b.) drop the release branch and tag from my github account 
and re-roll the release without any weird RC hacks.

Will do that, 
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub

> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau :
> 
> Le ven. 16 nov. 2018 22:54, Gary Gregory  a écrit :
> 
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau 
>> wrote:
>> 
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>> écrit
>>> :
>>> 
 On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> >>> 
 wrote:
 
> Oki, now the full VOTE text!
> 
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
> 
> 
> The ASF staging repository is at
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> 
> The source zip is at
> 
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 
 
>>> 
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> 
 
 For me:
 
 $ sha512sum commons-pool2-2.6.1-src.zip
 
 
>>> 
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
 *commons-pool2-2.6.1-src.zip
 
 Which is not what you list above. Please advise.
 
>>> 
>>> Src vs source-release?
>>> 
>> 
>> That's the problem with inventing a new release process... why do we have
>> BOTH:
>> 
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>> 
>> And more importantly why are they _different_? Which one will be used in
>> the dist/release area?
>> 
> 
> 
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep IMHO
> 
> 
>> Gary
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 Gary
 
 
> 
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
> 
> I've created the release in a GIT manner and pushed the according
>>> changes
> to my ASF-linked github repo
> 
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> 
> 
 
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> 
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> <
 
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
 
> 
> This will get pushed to the ASF cannonical repo once the VOTE
>> succeeds.
> 
> Site will be updated once the release has passed.
> 
> Please VOTE:
> 
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_
>>> is
> missing!)
> 
> 
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
> 
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>> > :
>> 
>> PS: I've created the release in a GIT manner and pushed the
>> according
> changes to my ASF-linked github repo
>> 
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> 
> 
 
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>> 
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>> 
>> This will get pushed to the ASF cannonical