On 10/5/19 5:47 AM, Gary Gregory wrote:
On Sat, Oct 5, 2019 at 8:17 AM sebb <seb...@gmail.com> wrote:

On Sat, 5 Oct 2019 at 02:32, Gary Gregory <garydgreg...@gmail.com> wrote:
Hi Phil and all:

It looks like you merged from the "old" git repo
https://git-wip-us.apache.org/repos/asf/commons-pool

I am not sure why we have two named repos but I am basing my work on
GitBox
https://gitbox.apache.org/repos/asf/commons-pool.git

I think these are in fact the same (?) and the confusion (on my part)
only
comes in due to seeing the "old" name in the Git commit history.

I am not sure if this matters aside from the confusion. Can anyone
elucidate?
Try browsing to the two URLs.

Do you see any difference in the displayed pages (apart from the URL)?

Not after looking for 30 seconds, and that's exactly my point: it is
_confusing_. Are they really _exactly_ the same? Which one is the
canonical one? Are there two repos or one?
It would help us all if we standardize on GitBox IMO.


Sorry for the screw-up.  I think when I set up the clone that I used to make that patch I was following [1].  We should change the URL there, I guess.

I will fix the setup on that box and verify that the logs look right.

Phil

[1] http://commons.apache.org/proper/commons-pool/scm.html



Gary


Thank you,
Gary

On Fri, Oct 4, 2019 at 9:06 PM Phil Steitz <phil.ste...@gmail.com>
wrote:
On 10/1/19 4:27 PM, Gary Gregory wrote:
On Tue, Oct 1, 2019 at 5:03 PM Phil Steitz <phil.ste...@gmail.com>
wrote:
Good news.  I think I now understand the actual root cause for
POOL-376.  Bad news is the fix that I committed masks but does not
really fix the problem.  I will update the ticket and commit a full
fix
this evening.  I will try to get a test case but that is going to be
tricky because it requires a race between the evictor and a borrower
under the right conditions.

Great news! Thank you Phil.
Sorry, it was POOL-326 that I was still missing a test for.  I just
added that and a real fix for the issue. See comments on the ticket for
what was going on there and the unit test I added to the GKOP tests.
Review of the fix would be good before rolling the release.

Phil
Gary


Phil


On 9/28/19 3:56 PM, Gary Gregory wrote:
On Sat, Sep 28, 2019, 16:43 Phil Steitz <phil.ste...@gmail.com>
wrote:
Well,  I don’t have one as I don’t have a test case in hand that
creates
the condition other than my hacked version of [performance] that
reliably
reproduces it before my last commit (and doesn’t after it).  I
have a
plane
ride tomorrow when I can make another go at it.  So let’s say
give me
48
hours and if I still have no test case, I would say cut the
release
without
it.

Sound good.

Gary


Phil

On Sep 28, 2019, at 2:10 PM, Gary Gregory <
garydgreg...@gmail.com>
wrote:
Phil (sorry for too post; phone),

May you give me an ETA so I can plan my time accordingly?

Thank you,
Gary

On Thu, Sep 26, 2019, 20:22 Gary Gregory <
garydgreg...@gmail.com>
wrote:
On Thu, Sep 26, 2019 at 5:57 PM Phil Steitz <
phil.ste...@gmail.com
wrote:
On 9/25/19 6:10 PM, Gary Gregory wrote:
On Wed, Sep 25, 2019 at 9:05 PM Phil Steitz <
phil.ste...@gmail.com>
wrote:
On 9/25/19 5:47 PM, Gary Gregory wrote:
On Wed, Sep 25, 2019 at 8:32 PM Phil Steitz <
phil.ste...@gmail.com>
wrote:
I would say yes, but I would also like to add a fix for the
similarly
nasty POOL-326.  I can do that in the next 24 hours. While
I
still
don't
have a test case hitting it and I am not satisfied with my
understanding
of why the createCount counter gets messed up, the fix in
my
last
comment on that ticket (check the size of idleObjects
instead
of
relying
on createCount) will eliminate the NPE.  I think we should
make
that
change and push a release with that fix bundled too.

OK, sounds good. I'll wait for your go signal.
I just pushed the fix for POOL-326.

OK, I should be able to get to an RC tomorrow. Hopefully
someone
else
can
validate the fix on their set up...
I am also still working on a test case.

I will hold off...

Gary


Phil
Gary


Phil
Garye

Phil

Hi All,

Is the fix for POOL-376 important enough to warrant an
ASAP
release?
Gayr

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



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

Reply via email to