Re: [DRAFT] June Report to the Board

[Phil Steitz]

On Sat, Jun 15, 2024 at 12:27 PM Gary Gregory 
wrote:

> Hm, would using GitHub Issues instead of Jira make the trail following
> easier, harder, or the same?
>

Harder, because then you would have to search yet another place to
reconstruct history.  But that would be less of an issue over time.  I
don't see how it would make it better.  What bugs me is not so much having
to look in multiple places as the degraded discussion.  We never had
"roadblocks" before - just a convention that we use the dev list to talk
about substantive issues.  JIRA (or Bugzilla or Github Issues or
) is for users to report bugs, ask for enhancements,
organize work, mark things as done. etc.  commits@, github PR review,
next_cool_review_board  is to enable review of proposed or committed code.
The ML is for discussion.  Trying to force all discussion into PR "threads"
has two big problems: 0) it lacks threading and unless we just drop dev@ it
fragments discussion 1) it causes things to be discussed late.  It works
great for trivial changes but for things that significantly change
performance or behavior or where there are a lot of different ways they
could be done, it is way better to actually talk about them rather than
just hack a PR and try to collectively mutate it into something acceptable.

Phil

>
> Gary
>
> On Sat, Jun 15, 2024, 2:58 PM Gary Gregory 
> wrote:
>
> > If we want to have everything recorded in one place, then we need to put
> > up some roadblocks to PRs, the Wiki, and Jira like ... what? Have a PR,
> > wiki, and Jira template/gate that says... you must discuss your
> > issue/bug/feature first on the mailing list? It does not feel workable.
> >
> > I don't think this is about people being dinosaurs, it's just the
> > technology and processes that are changing. I really like working with
> > GitHub PRs and GitHub CI builds. I don't want to go back to emails only
> > just like don't ever want to use an IRC thing.
> >
> > Some people don't want to create a GitHub account, so it's Jira and diff
> > files for them, but that's rare. BUT it gives us a LOT MORE work to
> > validate a patch compared to GitHub CI where it can use many OSs and Java
> > version while I'm sleeping :-)
> >
> > Gary
> >
> >
> > On Sat, Jun 15, 2024, 2:00 PM Phil Steitz  wrote:
> >
> >> On Sat, Jun 15, 2024 at 10:19 AM Gary Gregory 
> >> wrote:
> >>
> >> > Note that it is 1) awkward to say "Let's stop talking about this PR in
> >> > this PR"
> >>
> >>
> >> Funny we used to do that all the time in Jira comments.  I guess times
> >> change.  FWIW, I think it is a step backward in discussion and
> ultimately
> >> code and archive quality.  To me it is "awkward" to have to be
> constantly
> >> @somebody and not have threads or definitive discussion anywhere.  Works
> >> fine for trivial changes but does not really work for substantive
> >> discussion of bigger things.  So we end up never actually having those
> >> discussions and there is no reasonably searchable archive of the thought
> >> process that led to the changes going in.  We used to have that and it
> was
> >> a useful thing, especially for the more complex components.
> >>
> >> Phil
> >>
> >>
> >>
> >> > and 2) "You need to subscribe to a mailing to continue this
> >> > chat." It's just hard to find when to ask for a switch. Especially
> >> > when GH has a nice UI to make comments _about code_. Over at Log4j, we
> >> > now use GitHub issues instead of Jira, furthering the split...
> >> >
> >> > Gary
> >> >
> >> > On Sat, Jun 15, 2024 at 12:38 PM Phil Steitz 
> >> > wrote:
> >> > >
> >> > > On Wed, Jun 12, 2024 at 10:58 AM Gary D. Gregory <
> ggreg...@apache.org
> >> >
> >> > > wrote:
> >> > >
> >> > > > On 2024/06/12 17:17:24 Phil Steitz wrote:
> >> > > > > On Wed, Jun 12, 2024 at 7:27 AM sebb  wrote:
> >> > > > >
> >> > > > > > On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory <
> >> ggreg...@apache.org
> >> > >
> >> > > > wrote:
> >> > > > > > >
> >> > > > > > > Hello All,
> >> > > > > > >
> >> > > > > > > Here is the draft of our board report for June I plan on
> >> > submitting
> >> > > > in 

Re: [apache/commons-lang] Reimplement RandomStringUtils on top of SecureRandom#getInstanceStrong() (PR #1235)

[Phil Steitz]

On Fri, Jun 14, 2024 at 4:13 PM Fabrice Benhamouda 
wrote:

> Thanks @psteitz  ! I am not sure where is the
> best place to post the following comment. If you think it’s more
> appropriate to post it to the mailing list, let me know and I will post it
> there.
>
> To address the point "1) gen time performance cost", I’ve written some
> optimizations on top of the current PR: garydgregory#2
> 
>
> Benchmarking using JMH with JDK 8 on an AWS c6a.xlarge instance with
> cryptographic providers SUN/NativePRNG, SUN/SHA1PRNG, ACCP
>  1.6, and
> ACCP  2.3,
> we have the following results. Compared to the current state (with the
> default java.util.Random/ThreadLocalRandom number generator), when any of
> the above SecureRandom is used with the optimized code, the time to
> generate random alphabetic, alphanumeric, and numeric strings of at least
> 16 characters is less than three times slower (and sometimes even 5x
> faster). For 4-character strings, we observe a slow-down of at most 8x.
>
> If the optimized RandomStringUtils is called concurrently in multiple
> threads, the SUN/NativePrng SecureRandom implementation (the default on
> Linux) may be slower as calls are serialized (due to access to/dev/random.
>
This is the use case I would be most concerned with.  Many web applications
use this class in multi-threaded app server settings.  I would not use the
class in web apps after this change for that reason.  If we do make the
change, we should make it clear in the class javadoc that it is using
SecureRandom and prone to occasional stalls.

Since there was no discussion about why this change is being made, I will
ask again why it is being proposed.  The only rationale that I can see is
that somehow some users are using the class to generate things that should
be cryptographically secure, like passwords or hash salt, so to protect
these users, we make all other users take a potential performance hit.
Much better, IMO, would be to make the recommended improvements in
performance to the vanilla Random-based impl and add a new class or somehow
shoehorn in a secure impl for users that want / need that.

Phil

This seems an unlikely scenario in practice. In addition, switching to ACCP
2 for SecureRandom would fix the performance issue in that case.

> —
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> You are receiving this because you were mentioned.Message ID:
> 
>

Re: [DRAFT] June Report to the Board

[Phil Steitz]

On Sat, Jun 15, 2024 at 10:19 AM Gary Gregory 
wrote:

> Note that it is 1) awkward to say "Let's stop talking about this PR in
> this PR"


Funny we used to do that all the time in Jira comments.  I guess times
change.  FWIW, I think it is a step backward in discussion and ultimately
code and archive quality.  To me it is "awkward" to have to be constantly
@somebody and not have threads or definitive discussion anywhere.  Works
fine for trivial changes but does not really work for substantive
discussion of bigger things.  So we end up never actually having those
discussions and there is no reasonably searchable archive of the thought
process that led to the changes going in.  We used to have that and it was
a useful thing, especially for the more complex components.

Phil



> and 2) "You need to subscribe to a mailing to continue this
> chat." It's just hard to find when to ask for a switch. Especially
> when GH has a nice UI to make comments _about code_. Over at Log4j, we
> now use GitHub issues instead of Jira, furthering the split...
>
> Gary
>
> On Sat, Jun 15, 2024 at 12:38 PM Phil Steitz 
> wrote:
> >
> > On Wed, Jun 12, 2024 at 10:58 AM Gary D. Gregory 
> > wrote:
> >
> > > On 2024/06/12 17:17:24 Phil Steitz wrote:
> > > > On Wed, Jun 12, 2024 at 7:27 AM sebb  wrote:
> > > >
> > > > > On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory  >
> > > wrote:
> > > > > >
> > > > > > Hello All,
> > > > > >
> > > > > > Here is the draft of our board report for June I plan on
> submitting
> > > in a
> > > > > day or so, feedback is welcome.
> > > > > >
> > > > > > ## Description:
> > > > > > The mission of Apache Commons is the creation and maintenance of
> Java
> > > > > focused
> > > > > > reusable libraries and components
> > > > > >
> > > > > > ## Project Status:
> > > > > > Current project status: Ongoing with moderate activity.
> > > > > > Issues for the board: none.
> > > > > >
> > > > > > ## Membership Data:
> > > > > > Apache Commons was founded 2007-06-19 (17 years ago)
> > > > > > There are currently 149 committers and 44 PMC members in this
> > > project.
> > > > > > The Committer-to-PMC ratio is roughly 5:2.
> > > > >
> > > > > Missing from this paragraph is the fact that Commons has enabled
> > > > > universal commit.
> > > > >
> > > > > > Community changes, past quarter:
> > > > > > - Claude Warren was added to the PMC on 2024-03-22
> > > > > > - No new committers. Last addition was Claude Warren on
> 2022-02-01.
> > > > > >
> > > > > > ## Project Activity:
> > > > > > Many releases of our components:
> > > > > > CONFIGUATION-2.11.0 was released on 2024-06-10.
> > > > >
> > > > > Is that a new component?
> > > > >
> > > > > > NET-3.11.1 was released on 2024-06-10.
> > > > > > PARENT-71 was released on 2024-06-10.
> > > > > > JEXL-3.4.0 was released on 2024-06-06.
> > > > > > NET-3.11.0 was released on 2024-05-31.
> > > > > > VALIDATOR-1.9.0 was released on 2024-05-28.
> > > > > > JCS-3.2.1 was released on 2024-05-27.
> > > > > > DAEMON-1.4.0 was released on 2024-05-24.
> > > > > > CLI-1.8.0 was released on 2024-05-23.
> > > > > > COMPRESS-1.26.2 was released on 2024-05-23.
> > > > > > LOGGING-1.3.2 was released on 2024-05-15.
> > > > > > PARENT-70 was released on 2024-05-15.
> > > > > > CSV-1.11.0 was released on 2024-05-02.
> > > > > > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > > > > > CLI-1.7.0 was released on 2024-04-18.
> > > > > > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > > > > > TEXT-1.12.0 was released on 2024-04-16.
> > > > > > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > > > > > IO-2.16.1 was released on 2024-04-08.
> > > > > > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > > > > > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > > > > > PARENT-69 was relea

Re: [VOTE] Release Apache Commons Collections 4.5.0-M2 based on RC1

[Phil Steitz]

+1

Build, sigs, notes, all look good to me.

Tested on
apache-maven-3.9.3
Java version: 17.0.11, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
OS name: "linux", version: "5.15.0-107-generic", arch: "amd64", family:
"unix"

Some non-blocker comments:

0) There are quite a few javadoc warnings
1) SpotBugs errors should be suppressed or addressed
2) Checkstyle report is strangely wonky.  RAT is fine and headers look fine
to me, but Checkstyle is, um, confused

Phil

On Fri, Jun 14, 2024 at 7:49 PM Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.5.0-M1 was released, so I would like to release Apache
> Commons Collections 4.5.0-M2.
>
> Apache Commons Collections 4.5.0-M2 RC1 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.5.0-M2-RC1
> (svn revision 69753)
>
> The Git tag commons-collections-4.5.0-M2-RC1 commit for this RC is
> c92828a71367a4208d380e614f633d0196b5ad27 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=c92828a71367a4208d380e614f633d0196b5ad27
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-collections.git
> --branch
> 
> commons-collections-4.5.0-M2-RC1
> commons-collections-4.5.0-M2-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1743/org/apache/commons/commons-collections4/4.5.0-M2/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jun 15 02:29:00 UTC 2024
>
> commons-collections4-4.5.0-M2-bin.tar.gz=277ec5079fe3d0e9783aaa49a9eb6e486b2f917f54ea369d6c3a0bfd38f4b0525f57ead9d2004615f459b0a3a1a0217d00f3638a2171afd504feb185992a6e38
>
> commons-collections4-4.5.0-M2-bin.zip=95fb06b1ab80d0769acc41ceef3349c2efe14513bf4ebb66b000b4781264c5054b04b275133b989f3080291deca3a8561b228910bb55588bbcdcaf47f938164c
>
> commons-collections4-4.5.0-M2-bom.json=a7cbaa38b9ba7e674f694ca0f71a45b9e787cf4ad42d7a2e220f36030dd7d3307c12f99f16dcbde7c8457cd76d554b5619d0fa88849f58096a86b71ee9077028
>
> commons-collections4-4.5.0-M2-bom.xml=11f612198e324da771eb6496a2fad59e884d368a0c008b5fa7943fceea1014a14dfdf7c7e49f23b87f67b6fc6fae01ed84fe4b842862461222e7f0b8d7e61aae
>
> commons-collections4-4.5.0-M2-javadoc.jar=8069b3bf23ddec37257147c73b03ed965f70afce721821294dea4c22b68b21963690409ad15f7e3eeb2b72b1151b5e4ca95f81c3c4a7a750716989269ab02890
>
> commons-collections4-4.5.0-M2-sources.jar=97a7ad53ea5539cc8730f3697f6114daa59f52f48ab913e1187ba5a595a7bdc7bd3a8d440efd9e6975d833b094debf3e62faf98818706fd9cad08b8fc34f4837
>
> commons-collections4-4.5.0-M2-src.tar.gz=8fe8c0c158254f44c7cc8744c9969e9a32fcd0642f56598c7a942da07c9fc88a6916cf07174e73f9a88f157fa0dbd56e829522f34b0c63ee129ebf923bcc42f7
>
> commons-collections4-4.5.0-M2-src.zip=32b8db011cd1c7a3b83b6ea2bb2b5c795636cf6ccaa83e277ecf1eb27f50469f3c5d3e1eedae606be190fad8baa1d5c04599701a6d84b52c0b56d44d7d1ec71d
>
> commons-collections4-4.5.0-M2-test-sources.jar=6dc1719b80f800be57dccfd05e959bc0f9f22aac0c9aca84c74b68d623e1bcae10346162347206fd28d66e4c8364d56c4e4998a4820898a259ca758c3054830d
>
> commons-collections4-4.5.0-M2-tests.jar=65b9e8f72a00daa586bba62e818aac348679f9afda5bcbf95c10d47e9d5e5e65c27518565ada2af56146ff09ccc1f5ad940eb123c3fb9c53bcc8624db3254e1c
>
> org.apache.commons_commons-collections4-4.5.0-M2.spdx.json=d3e8455335a09f92b7b1c470104384080d933d5f64d5fe96fde31645a1fef3168a5ce1f5f3be8a1f4da6318a11996a959c2485654b6ec9423d26c8347ff2294b
>
>
> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy
> -P jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "17.0.11" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 17.0.11+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing)
>
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> Java version: 17.0.11, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 4.4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.5.0-M2-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.5.0-M2-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.5.0-M2-RC1/site/index.html
> (note some *relative* links are broken and the 4.5.0-M2
> directories are not yet created - these will be OK once the site is
> deployed.)
>
> JApiCmp Report (compared to 4.4):
>
> https://dist.apache.org/repos/dist/dev/commons/collections/4.5.0-M

Re: [DRAFT] June Report to the Board

[Phil Steitz]

On Wed, Jun 12, 2024 at 10:58 AM Gary D. Gregory 
wrote:

> On 2024/06/12 17:17:24 Phil Steitz wrote:
> > On Wed, Jun 12, 2024 at 7:27 AM sebb  wrote:
> >
> > > On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory 
> wrote:
> > > >
> > > > Hello All,
> > > >
> > > > Here is the draft of our board report for June I plan on submitting
> in a
> > > day or so, feedback is welcome.
> > > >
> > > > ## Description:
> > > > The mission of Apache Commons is the creation and maintenance of Java
> > > focused
> > > > reusable libraries and components
> > > >
> > > > ## Project Status:
> > > > Current project status: Ongoing with moderate activity.
> > > > Issues for the board: none.
> > > >
> > > > ## Membership Data:
> > > > Apache Commons was founded 2007-06-19 (17 years ago)
> > > > There are currently 149 committers and 44 PMC members in this
> project.
> > > > The Committer-to-PMC ratio is roughly 5:2.
> > >
> > > Missing from this paragraph is the fact that Commons has enabled
> > > universal commit.
> > >
> > > > Community changes, past quarter:
> > > > - Claude Warren was added to the PMC on 2024-03-22
> > > > - No new committers. Last addition was Claude Warren on 2022-02-01.
> > > >
> > > > ## Project Activity:
> > > > Many releases of our components:
> > > > CONFIGUATION-2.11.0 was released on 2024-06-10.
> > >
> > > Is that a new component?
> > >
> > > > NET-3.11.1 was released on 2024-06-10.
> > > > PARENT-71 was released on 2024-06-10.
> > > > JEXL-3.4.0 was released on 2024-06-06.
> > > > NET-3.11.0 was released on 2024-05-31.
> > > > VALIDATOR-1.9.0 was released on 2024-05-28.
> > > > JCS-3.2.1 was released on 2024-05-27.
> > > > DAEMON-1.4.0 was released on 2024-05-24.
> > > > CLI-1.8.0 was released on 2024-05-23.
> > > > COMPRESS-1.26.2 was released on 2024-05-23.
> > > > LOGGING-1.3.2 was released on 2024-05-15.
> > > > PARENT-70 was released on 2024-05-15.
> > > > CSV-1.11.0 was released on 2024-05-02.
> > > > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > > > CLI-1.7.0 was released on 2024-04-18.
> > > > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > > > TEXT-1.12.0 was released on 2024-04-16.
> > > > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > > > IO-2.16.1 was released on 2024-04-08.
> > > > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > > > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > > > PARENT-69 was released on 2024-04-01.
> > > > IO-2.16.0 was released on 2024-03-28.
> > > > LOGGING-1.3.1 was released on 2024-03-24.
> > > > PARENT-68 was released on 2024-03-23.
> > > > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > > > CONFIGURATION-2.10.0 was released on 2024-03-13.
> > >
> > > The above list should probably be sorted
> > >
> > > > ## Community Health:
> > > > We welcomed Claude Warren as our latest PMC member. Mailing list
> > > activity has
> > > > increased.
> > >
> > > Much of the increased mailing list activity is driven by dependabot
> > > PRs, many of which are useless, as it does not take Java compatibility
> > > into account.
> > >
> >
> > +1
> > I have had to filter out most of the messages and once I do that, there
> is
> > almost no actual discussion on-list.  I am worried that when people do
> try
> > to start discussion, the messages are being missed.  I personally see the
> > lack of ml discussion as a problem.  Lots of code changes are happening
> > with no discussion, other than maybe random nits on PRs ending up in
> github
> > threads that don't end up organized that well in list archives.  This
> > problem is not unique to Commons.
>
> Hi Phil,
>
> We had a discussion a while back about creating a "bot" email list but:
> - no one actually proposed anything concrete and did any work
> - we already have bot lists like "commit", "notifications", "issues",
> can't we reuse those?
>

+1 for that.  How about moving the dependabot things to "notifications"?
What exactly do

Re: [DRAFT] June Report to the Board

[Phil Steitz]

Thanks, Gary

Phil

On Wed, Jun 12, 2024 at 10:37 AM Gary D. Gregory 
wrote:

> I've edited the sections commented on as:
>
> ## Project Activity:
> Many releases of our components:
> CONFIGURATION-2.11.0 was released on 2024-06-10.
> NET-3.11.1 was released on 2024-06-10.
> PARENT-71 was released on 2024-06-10.
> JEXL-3.4.0 was released on 2024-06-06.
> NET-3.11.0 was released on 2024-05-31.
> VALIDATOR-1.9.0 was released on 2024-05-28.
> JCS-3.2.1 was released on 2024-05-27.
> DAEMON-1.4.0 was released on 2024-05-24.
> CLI-1.8.0 was released on 2024-05-23.
> COMPRESS-1.26.2 was released on 2024-05-23.
> LOGGING-1.3.2 was released on 2024-05-15.
> PARENT-70 was released on 2024-05-15.
> CSV-1.11.0 was released on 2024-05-02.
> RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> CLI-1.7.0 was released on 2024-04-18.
> IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> TEXT-1.12.0 was released on 2024-04-16.
> BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> IO-2.16.1 was released on 2024-04-08.
> COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> PARENT-69 was released on 2024-04-01.
> IO-2.16.0 was released on 2024-03-28.
> LOGGING-1.3.1 was released on 2024-03-24.
> PARENT-68 was released on 2024-03-23.
> CONFIGURATION-2.10.1 was released on 2024-03-20.
> CONFIGURATION-2.10.0 was released on 2024-03-13.
>
> ## Community Health:
> We welcomed Claude Warren as our latest PMC member. Mailing list activity
> has
> increased mostly due to GitHub automated emails. Most if not all of our
> growth
> in contributions are coming in through GitHub pull requests. GitHub PRs
> with
> our use of GitHub continuous integration builds provide
> validation of PRs and the existing code base. The flip side is that the
> increase in GitHub usage is matched by a decrease in Jira usage.
>
> Gary
>
> On 2024/06/12 14:17:50 Gilles Sadowski wrote:
> > Hi.
> >
> > Le mer. 12 juin 2024 à 15:45, Gary D. Gregory  a
> écrit :
> > >
> > > Hello All,
> > >
> > > Here is the draft of our board report for June I plan on submitting in
> a day or so, feedback is welcome.
> > >
> > > ## Description:
> > > The mission of Apache Commons is the creation and maintenance of Java
> focused
> > > reusable libraries and components
> > >
> > > ## Project Status:
> > > Current project status: Ongoing with moderate activity.
> > > Issues for the board: none.
> > >
> > > ## Membership Data:
> > > Apache Commons was founded 2007-06-19 (17 years ago)
> > > There are currently 149 committers and 44 PMC members in this project.
> > > The Committer-to-PMC ratio is roughly 5:2.
> > >
> > > Community changes, past quarter:
> > > - Claude Warren was added to the PMC on 2024-03-22
> > > - No new committers. Last addition was Claude Warren on 2022-02-01.
> > >
> > > ## Project Activity:
> > > Many releases of our components:
> > > CONFIGUATION-2.11.0 was released on 2024-06-10.
> > > NET-3.11.1 was released on 2024-06-10.
> > > PARENT-71 was released on 2024-06-10.
> > > JEXL-3.4.0 was released on 2024-06-06.
> > > NET-3.11.0 was released on 2024-05-31.
> > > VALIDATOR-1.9.0 was released on 2024-05-28.
> > > JCS-3.2.1 was released on 2024-05-27.
> > > DAEMON-1.4.0 was released on 2024-05-24.
> > > CLI-1.8.0 was released on 2024-05-23.
> > > COMPRESS-1.26.2 was released on 2024-05-23.
> > > LOGGING-1.3.2 was released on 2024-05-15.
> > > PARENT-70 was released on 2024-05-15.
> > > CSV-1.11.0 was released on 2024-05-02.
> > > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > > CLI-1.7.0 was released on 2024-04-18.
> > > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > > TEXT-1.12.0 was released on 2024-04-16.
> > > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > > IO-2.16.1 was released on 2024-04-08.
> > > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > > PARENT-69 was released on 2024-04-01.
> > > IO-2.16.0 was released on 2024-03-28.
> > > LOGGING-1.3.1 was released on 2024-03-24.
> > > PARENT-68 was released on 2024-03-23.
> > > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > > CONFIGURATION-2.10.0 was released on 2024-03-13.
> > >
> > > ## Community Health:
> > > We welcomed Claude Warren as our latest PMC member. Mailing list
> activity has
> > > increased. Most if not all of our increasing contributions are coming
> in
> > > through GitHub pull requests. This is working well for us:
> >
> > It is just one opinion, which I (still) do not share.
> > [Not denying the many utilities readily available from GH; the
> > issues lay elsewhere...]
> >
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-

Re: [COLLECTIONS] documentation question

[Phil Steitz]

On Sat, Jun 15, 2024 at 8:19 AM Claude Warren  wrote:

> Greetings,
>
> I see that we support xml documents for documentation but does anyone know
> if markdown is supported?  I have a number of markdown based documents that
> would work well for the Bloom filter documentation, but translating to XML
> will be a pain.
>

I know in the past some sites have used the now archaic apt format along
with the similarly ancient xdoc that most sites use.  I think the maven
site plugin allows you to combine content from different formats and
markdown is now a supported format, so this should not be a problem.  I
don't think you need to transform all of the site content to do that, but I
doubt anyone would complain - and many would be thankful - if you did.  See
[1].

Phil
[1]
https://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html


>
> thanks,
> Claude
>

Re: [DRAFT] June Report to the Board

[Phil Steitz]

On Wed, Jun 12, 2024 at 7:27 AM sebb  wrote:

> On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory  wrote:
> >
> > Hello All,
> >
> > Here is the draft of our board report for June I plan on submitting in a
> day or so, feedback is welcome.
> >
> > ## Description:
> > The mission of Apache Commons is the creation and maintenance of Java
> focused
> > reusable libraries and components
> >
> > ## Project Status:
> > Current project status: Ongoing with moderate activity.
> > Issues for the board: none.
> >
> > ## Membership Data:
> > Apache Commons was founded 2007-06-19 (17 years ago)
> > There are currently 149 committers and 44 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 5:2.
>
> Missing from this paragraph is the fact that Commons has enabled
> universal commit.
>
> > Community changes, past quarter:
> > - Claude Warren was added to the PMC on 2024-03-22
> > - No new committers. Last addition was Claude Warren on 2022-02-01.
> >
> > ## Project Activity:
> > Many releases of our components:
> > CONFIGUATION-2.11.0 was released on 2024-06-10.
>
> Is that a new component?
>
> > NET-3.11.1 was released on 2024-06-10.
> > PARENT-71 was released on 2024-06-10.
> > JEXL-3.4.0 was released on 2024-06-06.
> > NET-3.11.0 was released on 2024-05-31.
> > VALIDATOR-1.9.0 was released on 2024-05-28.
> > JCS-3.2.1 was released on 2024-05-27.
> > DAEMON-1.4.0 was released on 2024-05-24.
> > CLI-1.8.0 was released on 2024-05-23.
> > COMPRESS-1.26.2 was released on 2024-05-23.
> > LOGGING-1.3.2 was released on 2024-05-15.
> > PARENT-70 was released on 2024-05-15.
> > CSV-1.11.0 was released on 2024-05-02.
> > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > CLI-1.7.0 was released on 2024-04-18.
> > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > TEXT-1.12.0 was released on 2024-04-16.
> > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > IO-2.16.1 was released on 2024-04-08.
> > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > PARENT-69 was released on 2024-04-01.
> > IO-2.16.0 was released on 2024-03-28.
> > LOGGING-1.3.1 was released on 2024-03-24.
> > PARENT-68 was released on 2024-03-23.
> > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > CONFIGURATION-2.10.0 was released on 2024-03-13.
>
> The above list should probably be sorted
>
> > ## Community Health:
> > We welcomed Claude Warren as our latest PMC member. Mailing list
> activity has
> > increased.
>
> Much of the increased mailing list activity is driven by dependabot
> PRs, many of which are useless, as it does not take Java compatibility
> into account.
>

+1
I have had to filter out most of the messages and once I do that, there is
almost no actual discussion on-list.  I am worried that when people do try
to start discussion, the messages are being missed.  I personally see the
lack of ml discussion as a problem.  Lots of code changes are happening
with no discussion, other than maybe random nits on PRs ending up in github
threads that don't end up organized that well in list archives.  This
problem is not unique to Commons.

Phil

>
>
> > Most if not all of our increasing contributions are coming in
> > through GitHub pull requests. This is working well for us: GitHub PRs
> with
> > continuous integration builds providing great infrastructure and
> validation of
> > PRs and the existing code base. The flip side is that the increase in
> GitHub
> > usage is matched by a decrease in Jira usage.
> >
> > Gary
> >
> > -
> > 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] Release Apache Commons Net 3.11.1 based on RC1

[Phil Steitz]

+1
Modulo comment above on findbugs, all looks good.  Tested full site build,
reports, sigs, on
Apache Maven 3.9.3
Java version: 17.0.11, openjdk
OS name: "linux", version: "5.15.0-107-generic", arch: "amd64", family:
"unix"
Compiled and ran tests on
Java version: 19.0.2, vendor: Private Build, runtime:
/usr/lib/jvm/java-19-openjdk-amd64
OS name: "linux", version: "5.15.146.1-microsoft-standard-wsl2", arch:
"amd64", family: "unix"

Two suggestions for improvement for future release:
0) Address findbugs issues and set up build to fail on findbugs errors
1) Introduce backward compatibility tests

Phil




On Fri, Jun 7, 2024 at 5:40 AM Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Net 3.11.0 was released, so I would like to release Apache Commons Net
> 3.11.1.
>
> Apache Commons Net 3.11.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1 (svn
> revision 69595)
>
> The Git tag commons-net-3.11.1-RC1 commit for this RC is
> 0505563df6664a8c5b5fad6897cd373aba809c64 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=0505563df6664a8c5b5fad6897cd373aba809c64
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-net.git
> --branch 
> commons-net-3.11.1-RC1 commons-net-3.11.1-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1738/commons-net/commons-net/3.11.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Jun 07 12:26:06 UTC 2024
>
> commons-net-3.11.1-bin.tar.gz=90c1e62d8fe1d8c26588fbfefeb41f6ef16a349b8851e75297363c7d2eca5cb27d313a11e2f532f9b9c8b2790f1b9636f39c5fd563a6e9403ac6363415245bd9
>
> commons-net-3.11.1-bin.zip=e2e378d247ab4a1260d01c18579abe247bcca05246b9340edfb07f7bf5aa216ea745f590696bda9d43806b273ef8f8e73ed7a60b4f47f77dab45a5f657467fba
>
> commons-net-3.11.1-bom.json=f954bd7d2560a423b2c93f78d92cc6b658c5fab66465bc0adb3e455385448f8b32f0319c229703645a8ad9cae88dccb689e6783e85d4f450671d7563a485ac3d
>
> commons-net-3.11.1-bom.xml=0937d4448e3c52987ab3ba9268ebe68ab85e748a394d1c75efa6682dd265bd159c7f6c8e0bbb10fa61f2f13675ebb8d7753b2fefadee96be1e4c9da391bf9aff
>
> commons-net-3.11.1-javadoc.jar=fe46639c1df071ec1e4f785ff4c2b55f8b0604a3d90b9395852f9be4a4b57a9e490ab985a79fc29a6e287944a2cfc2352837685eb01795f5647ec5c95b6cbd43
>
> commons-net-3.11.1-sources.jar=9aa64b66154ee1775d9af6b8d99e9cb771c5234545df716e2273eb9a050cd683dda3d8520b660207f23229ccaf08533f6339ebfbb75210d0ff43df41d7419e33
>
> commons-net-3.11.1-src.tar.gz=0999067cc73cb0e0ab4940302180a0afa998b37c51f93c1c744bf1d346d14c89283166a665283d98200e98f0b8c39854f17493890d49ddad5769c4deb49de37e
>
> commons-net-3.11.1-src.zip=6820a334da2b4144acbd73e8f254bcd39cf46d83ecd4974d11e97c84fb573d78132546ac05530b3a88f7db3e59a3660600f3436716cd76c44016c797302ec8a9
>
> commons-net-3.11.1-test-sources.jar=0697dfe901f6f2f307c3ea813c22181c90b0b762549cc8a9e3e0394dadb2b5868e46b307630608a34df973ca5d6e346eb36823ae2a58d8d62d20ad47be3463dd
>
> commons-net-3.11.1-tests.jar=be5614c73ca8fe1f78ce58cc735ee34a32698ec956407562383b8257eb19a8211c0ca448507f4bfaf1bb85bbc6b3bb189edbbbfb71b5d92b5e113af579c74810
>
> commons-net-examples-3.11.1.jar=160512e72ae002e4214a23d0d20694295b8265a19a7889183e130d0b9e17f4a5edb22b12d3492e505269e3427935ff17d0f3f29557dd09103b68473df4648566
>
> commons-net-ftp-3.11.1.jar=1fc341b3ef5759858b355495d1d07fe8fdc4f6773d4619db6b67f86c39e60e7f25e208e2a4da7fa306172b7aca557c1a521144329cd6059ceaab603b7944f552
>
> commons-net_commons-net-3.11.1.spdx.json=0ccf4994b061451d93d1225a8960483bbfcf5e87d03caac8ed0d7e7a6e815d07b34d76c401156b2246829a30554dcb61419a6766b35451ad12a6251fa0f1eef9
>
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "21.0.3" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 21.0.3)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.3, mixed mode, sharing)
>
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> Java version: 21.0.3, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@21/21.0.3/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 3.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/index.html
> (note some *relative* links are broken and the 3.11.1 directories
> are not ye

Re: [VOTE] Release Apache Commons Net 3.11.1 based on RC1

[Phil Steitz]

There are a bunch of findbugs errors reported.  Is this expected?

Phil

On Fri, Jun 7, 2024 at 5:40 AM Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Net 3.11.0 was released, so I would like to release Apache Commons Net
> 3.11.1.
>
> Apache Commons Net 3.11.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1 (svn
> revision 69595)
>
> The Git tag commons-net-3.11.1-RC1 commit for this RC is
> 0505563df6664a8c5b5fad6897cd373aba809c64 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=0505563df6664a8c5b5fad6897cd373aba809c64
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-net.git
> --branch 
> commons-net-3.11.1-RC1 commons-net-3.11.1-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1738/commons-net/commons-net/3.11.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Jun 07 12:26:06 UTC 2024
>
> commons-net-3.11.1-bin.tar.gz=90c1e62d8fe1d8c26588fbfefeb41f6ef16a349b8851e75297363c7d2eca5cb27d313a11e2f532f9b9c8b2790f1b9636f39c5fd563a6e9403ac6363415245bd9
>
> commons-net-3.11.1-bin.zip=e2e378d247ab4a1260d01c18579abe247bcca05246b9340edfb07f7bf5aa216ea745f590696bda9d43806b273ef8f8e73ed7a60b4f47f77dab45a5f657467fba
>
> commons-net-3.11.1-bom.json=f954bd7d2560a423b2c93f78d92cc6b658c5fab66465bc0adb3e455385448f8b32f0319c229703645a8ad9cae88dccb689e6783e85d4f450671d7563a485ac3d
>
> commons-net-3.11.1-bom.xml=0937d4448e3c52987ab3ba9268ebe68ab85e748a394d1c75efa6682dd265bd159c7f6c8e0bbb10fa61f2f13675ebb8d7753b2fefadee96be1e4c9da391bf9aff
>
> commons-net-3.11.1-javadoc.jar=fe46639c1df071ec1e4f785ff4c2b55f8b0604a3d90b9395852f9be4a4b57a9e490ab985a79fc29a6e287944a2cfc2352837685eb01795f5647ec5c95b6cbd43
>
> commons-net-3.11.1-sources.jar=9aa64b66154ee1775d9af6b8d99e9cb771c5234545df716e2273eb9a050cd683dda3d8520b660207f23229ccaf08533f6339ebfbb75210d0ff43df41d7419e33
>
> commons-net-3.11.1-src.tar.gz=0999067cc73cb0e0ab4940302180a0afa998b37c51f93c1c744bf1d346d14c89283166a665283d98200e98f0b8c39854f17493890d49ddad5769c4deb49de37e
>
> commons-net-3.11.1-src.zip=6820a334da2b4144acbd73e8f254bcd39cf46d83ecd4974d11e97c84fb573d78132546ac05530b3a88f7db3e59a3660600f3436716cd76c44016c797302ec8a9
>
> commons-net-3.11.1-test-sources.jar=0697dfe901f6f2f307c3ea813c22181c90b0b762549cc8a9e3e0394dadb2b5868e46b307630608a34df973ca5d6e346eb36823ae2a58d8d62d20ad47be3463dd
>
> commons-net-3.11.1-tests.jar=be5614c73ca8fe1f78ce58cc735ee34a32698ec956407562383b8257eb19a8211c0ca448507f4bfaf1bb85bbc6b3bb189edbbbfb71b5d92b5e113af579c74810
>
> commons-net-examples-3.11.1.jar=160512e72ae002e4214a23d0d20694295b8265a19a7889183e130d0b9e17f4a5edb22b12d3492e505269e3427935ff17d0f3f29557dd09103b68473df4648566
>
> commons-net-ftp-3.11.1.jar=1fc341b3ef5759858b355495d1d07fe8fdc4f6773d4619db6b67f86c39e60e7f25e208e2a4da7fa306172b7aca557c1a521144329cd6059ceaab603b7944f552
>
> commons-net_commons-net-3.11.1.spdx.json=0ccf4994b061451d93d1225a8960483bbfcf5e87d03caac8ed0d7e7a6e815d07b34d76c401156b2246829a30554dcb61419a6766b35451ad12a6251fa0f1eef9
>
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "21.0.3" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 21.0.3)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.3, mixed mode, sharing)
>
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> Java version: 21.0.3, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@21/21.0.3/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 3.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/index.html
> (note some *relative* links are broken and the 3.11.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 3.11.0):
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really shoul

Re: [VOTE] Release Apache Commons Configuration 2.11.0 based on RC1

[Phil Steitz]

+1
Build, site, reports, api compatibility, release notes, sigs all OK
There were a bunch of javadoc warnings for missing javadoc, but not a
blocker for release.

Tested on
Apache Maven 3.9.3
Java version: 17.0.11, openjdk
OS name: "linux", version: "5.15.0-107-generic", arch: "amd64", family:
"unix"

Phil

On Fri, Jun 7, 2024 at 6:53 AM Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Configuration 2.10.1 was released, so I would like to release Apache
> Commons Configuration 2.11.0.
>
> Apache Commons Configuration 2.11.0 RC1 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1
> (svn revision 69603)
>
> The Git tag commons-configuration-2.11.0-RC1 commit for this RC is
> f428261556f4cba56a6d49a4824803cff056fbed which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f428261556f4cba56a6d49a4824803cff056fbed
> You may checkout this tag using:
> git clone
> https://gitbox.apache.org/repos/asf/commons-configuration.git
> --branch
> 
> commons-configuration-2.11.0-RC1
> commons-configuration-2.11.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1741/org/apache/commons/commons-configuration2/2.11.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Jun 07 13:40:47 UTC 2024
>
> commons-configuration2-2.11.0-bin.tar.gz=c77fcb1dfb66fc780e122348cc4991a08f89e41cdb06e60feb7c6151ea059a88924ce55ccf86f3d6563902c2903647047a5da45ad90752457dc00b3b546b0877
>
> commons-configuration2-2.11.0-bin.zip=30be0da66979268a71e4151fdc63ce02efa33351dba87260137108982759f3412f74bae4046e1c9c00ce10c592a67364be190e80428dbde7b451b347ba08d708
>
> commons-configuration2-2.11.0-bom.json=3a0a6abbcd240e195991ee6a67bf6cd23e5c661a88e88ced892449661e620297e91148e56de3efb0274aeaa90e793fdba7e1acb0c425fd05b438c62636fafd82
>
> commons-configuration2-2.11.0-bom.xml=4227e57f8aac9e06685a559d8123e058d7409ed1d6a3c8d1879c7a42628b3f30ee5d3c64e4d3a8621bc3d75ced0509987c1fb198151d12a0cab23966cdda07a0
>
> commons-configuration2-2.11.0-javadoc.jar=4da6c6d18c9834ae714dcbd68fd917dc8cd901b554427f2d1208cfc3aef284f37787433155e0a0ec10acbff3679c66a6a47b75fe10a3c067ce3fbabdcb697464
>
> commons-configuration2-2.11.0-sources.jar=0343f023a1da7cbe72b0059a2326d3d06d11f6471ee660cc183c38b602a2b2a4a631b715078c3a87dd437718c030658076794ea47e3932829fe8a3c2ce171a8f
>
> commons-configuration2-2.11.0-src.tar.gz=a7fa8d6599c54bf38eabe9be0458e657051d7db1785ee71c8187af4f084ed011e6325d245f2c8acc7cc15243feb6782804231e4fdca06cda184e58f11def305b
>
> commons-configuration2-2.11.0-src.zip=e60cc0384ff154888301e21772be59d7e61edfc0bf2ef16e3744caee6af25424fd3cf85664a98b46a0866d1bb42a3bdc943f4507b43bf8a2145a45ebb816c952
>
> commons-configuration2-2.11.0-test-sources.jar=2b2f9f3cca97fb697842d4c04760a7973b47fc64a0160b67c6188af984ca48ae1906627b8d97c698dc89fb3dc66c26368144ca137d5ac1a3a134703aa1833281
>
> commons-configuration2-2.11.0-tests.jar=3a283960e3f2ac488abdac0f460a4b68030513dad8ec7f6c8cf9b490fff2190441acff705152b9e77def9cd8b3dd9f989e86b64050e72b48700b3ad92c083788
>
> org.apache.commons_commons-configuration2-2.11.0.spdx.json=9e2f291cfd176ff243efd7007c0fde1e1d92a0bd6642b6bb659f8914c77c9f16b3da907050bae9ddb4ab11bd11cb2086b68bb5938c70878fa262a32bd1a26c56
>
> I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy
> -P jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "17.0.11" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 17.0.11+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing)
>
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> Java version: 17.0.11, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 2.10.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.11.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.10.1):
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1/site/rat-report.html
>
> KEYS:
>   https://download

Re: [pool] Resilience against factory outages (POOL-407)

[Phil Steitz]

Thx and sorry.

Phil

On Fri, May 31, 2024 at 1:45 PM Gary D. Gregory  wrote:

> Hello Phil,
>
> Before you push, run 'mvn' (buy itself), this runs the default goal, which
> contains all build checks.
>
> If see the code coverage report, regardless of coverage failures, run:
>
> mvn clean site -Dcommons.jacoco.haltOnFailure=false
>
> I'll update the readme...
>
> TY,
> Gary
>
> On 2024/05/31 20:12:09 Phil Steitz wrote:
> > The build worked locally for me fine.  I could not get the site to build.
> > Is there some sequence that I need to use to get the site to build?  I
> did
> > run Checksytle and Findbugs separately.  What is the test coverage plugin
> > and how do I run that?
> >
> > Phil
> >
> > On Fri, May 31, 2024 at 11:53 AM Gary Gregory 
> > wrote:
> >
> > > Hi Phil,
> > >
> > > Thank you for the note. I'll try to take a look soon.
> > >
> > > The new code causes the build to fail as it looks like not all of it is
> > > covered by unit tests.
> > >
> > > Gary
> > >
> > >
> > > On Fri, May 31, 2024, 2:29 PM Phil Steitz 
> wrote:
> > >
> > > > I just committed  a first attempt at providing the above, intended
> as a
> > > fix
> > > > for POOL-407 and a lot of similar issues reported over the years.
> The
> > > > scenario in POOL-407 is common when resource providers (like
> databases)
> > > go
> > > > down:
> > > >
> > > > 1. makeObject requests start to fail and threads line up waiting on
> the
> > > > deque.
> > > > 2. The provider comes back up so makes will succeed again, but the
> > > clients,
> > > > the pool and the factory are all ignorant of this fact, so no
> clients get
> > > > served.
> > > >
> > > > What I just committed puts the resilience responsibility on the
> factory,
> > > > having it monitor itself.  That responsibility could arguably be put
> > > > instead on the pool.
> > > >
> > > > To use the feature as is, you need to create a
> > > ResilientPooledObjectFactory
> > > > wrapping a PooledObjectFactory, configure it, attach it to its pool
> and
> > > > start its monitor.  The formerly disabled GOP test,
> > > > testLivenessOnTransientFactoryFailure, shows how to do it.  The
> setup is
> > > a
> > > > little awkward.  I would appreciate feedback on the following
> options for
> > > > how to improve it (or any other comments on the code):
> > > >
> > > > 0) Roll it back and come up with something better
> > > > 1) Leave as is
> > > > 2) add a GOP config that results in its factory being wrapped
> > > automatically
> > > > in a RPOF.
> > > > 3) move the functionality into the pool
> > > >
> > > > The other thing that needs to be designed is how to make the
> proactive
> > > make
> > > > attempt strategy configurable.  It is hard-coded now in the RPOF
> > > runChecks
> > > > and the Adder inner class.  The initial implementation is primitive:
> > > > Monitor the makeObject log.  Any failure triggers start of an Adder
> that
> > > > tries addObject with configurable delay and (hard-coded) max
> failures.
> > > > Once the circular log becomes filled with successes, turn the adder
> off.
> > > >
> > > > Also, RPOF spawns a monitoring thread and, when it detects a
> transient
> > > > failure, an adder thread.  Careful review - and improvement - of the
> > > > management of these threads would be appreciated.  I tried to make
> sure,
> > > > and added tests to confirm, that closing the pool kills these
> threads.
> > > >
> > > > Phil
> > > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [pool] Resilience against factory outages (POOL-407)

[Phil Steitz]

The build worked locally for me fine.  I could not get the site to build.
Is there some sequence that I need to use to get the site to build?  I did
run Checksytle and Findbugs separately.  What is the test coverage plugin
and how do I run that?

Phil

On Fri, May 31, 2024 at 11:53 AM Gary Gregory 
wrote:

> Hi Phil,
>
> Thank you for the note. I'll try to take a look soon.
>
> The new code causes the build to fail as it looks like not all of it is
> covered by unit tests.
>
> Gary
>
>
> On Fri, May 31, 2024, 2:29 PM Phil Steitz  wrote:
>
> > I just committed  a first attempt at providing the above, intended as a
> fix
> > for POOL-407 and a lot of similar issues reported over the years.  The
> > scenario in POOL-407 is common when resource providers (like databases)
> go
> > down:
> >
> > 1. makeObject requests start to fail and threads line up waiting on the
> > deque.
> > 2. The provider comes back up so makes will succeed again, but the
> clients,
> > the pool and the factory are all ignorant of this fact, so no clients get
> > served.
> >
> > What I just committed puts the resilience responsibility on the factory,
> > having it monitor itself.  That responsibility could arguably be put
> > instead on the pool.
> >
> > To use the feature as is, you need to create a
> ResilientPooledObjectFactory
> > wrapping a PooledObjectFactory, configure it, attach it to its pool and
> > start its monitor.  The formerly disabled GOP test,
> > testLivenessOnTransientFactoryFailure, shows how to do it.  The setup is
> a
> > little awkward.  I would appreciate feedback on the following options for
> > how to improve it (or any other comments on the code):
> >
> > 0) Roll it back and come up with something better
> > 1) Leave as is
> > 2) add a GOP config that results in its factory being wrapped
> automatically
> > in a RPOF.
> > 3) move the functionality into the pool
> >
> > The other thing that needs to be designed is how to make the proactive
> make
> > attempt strategy configurable.  It is hard-coded now in the RPOF
> runChecks
> > and the Adder inner class.  The initial implementation is primitive:
> > Monitor the makeObject log.  Any failure triggers start of an Adder that
> > tries addObject with configurable delay and (hard-coded) max failures.
> > Once the circular log becomes filled with successes, turn the adder off.
> >
> > Also, RPOF spawns a monitoring thread and, when it detects a transient
> > failure, an adder thread.  Careful review - and improvement - of the
> > management of these threads would be appreciated.  I tried to make sure,
> > and added tests to confirm, that closing the pool kills these threads.
> >
> > Phil
> >
>

[pool] Resilience against factory outages (POOL-407)

[Phil Steitz]

I just committed  a first attempt at providing the above, intended as a fix
for POOL-407 and a lot of similar issues reported over the years.  The
scenario in POOL-407 is common when resource providers (like databases) go
down:

1. makeObject requests start to fail and threads line up waiting on the
deque.
2. The provider comes back up so makes will succeed again, but the clients,
the pool and the factory are all ignorant of this fact, so no clients get
served.

What I just committed puts the resilience responsibility on the factory,
having it monitor itself.  That responsibility could arguably be put
instead on the pool.

To use the feature as is, you need to create a ResilientPooledObjectFactory
wrapping a PooledObjectFactory, configure it, attach it to its pool and
start its monitor.  The formerly disabled GOP test,
testLivenessOnTransientFactoryFailure, shows how to do it.  The setup is a
little awkward.  I would appreciate feedback on the following options for
how to improve it (or any other comments on the code):

0) Roll it back and come up with something better
1) Leave as is
2) add a GOP config that results in its factory being wrapped automatically
in a RPOF.
3) move the functionality into the pool

The other thing that needs to be designed is how to make the proactive make
attempt strategy configurable.  It is hard-coded now in the RPOF runChecks
and the Adder inner class.  The initial implementation is primitive:
Monitor the makeObject log.  Any failure triggers start of an Adder that
tries addObject with configurable delay and (hard-coded) max failures.
Once the circular log becomes filled with successes, turn the adder off.

Also, RPOF spawns a monitoring thread and, when it detects a transient
failure, an adder thread.  Careful review - and improvement - of the
management of these threads would be appreciated.  I tried to make sure,
and added tests to confirm, that closing the pool kills these threads.

Phil

Re: [VOTE] Release Apache Commons Validator 1.9.0 based on RC1

[Phil Steitz]

[+1]
Checked build, sigs, reports, notes.  All look good.
Tested on
Apache Maven 3.9.3
Java version: 17.0.10, java-17-openjdk-amd64
OS name: "linux", version: "5.15.0-107-generic", arch: "amd64", family:
"unix"

Phil


On Sat, May 25, 2024 at 2:12 PM Gary Gregory  wrote:

> We have fixed a few bugs and added enhancements since Apache Commons
> Validator 1.8.0 was released, so I would like to release Apache
> Commons Validator 1.9.0.
>
> Apache Commons Validator 1.9.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1
> (svn revision 69387)
>
> The Git tag commons-validator-1.9.0-RC1 commit for this RC is
> 191171b2fb1500d24c42a809cf13386ac8f4ecac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-validator.git;a=commit;h=191171b2fb1500d24c42a809cf13386ac8f4ecac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-validator.git
> --branch
> 
> commons-validator-1.9.0-RC1 commons-validator-1.9.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1734/commons-validator/commons-validator/1.9.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat May 25 20:36:23 UTC 2024
>
> commons-validator-1.9.0-bin.tar.gz=a755d2be1b9fb3cb75cb71c2c6143969eabd8ba48401dd86cad6c658e0de72e52a887e157ef38e780471382c2da68db228866303f3d4cb4500f995b8b3967476
>
> commons-validator-1.9.0-bin.zip=7c0cb444f4e162c46cbd356c8a3c8b166b06bcaf79b6c433ee5ad585498a1f0b4dfef3606ca4beedeef418b5b56209f86cac6dd2c1c8fa4dfe62c679df0018db
>
> commons-validator-1.9.0-bom.json=7e9baecc1b58f5de101d247b95d871a5b3227603a99eddf8bcce07e3656024dffc615b8ec0b765376bf640f9596581cb483830861878474fe79339bb84352cd3
>
> commons-validator-1.9.0-bom.xml=d4a5d380ade4eec7f7a71cb260a61901b5945129bc448894c89ae10d3375a4dac2898be6498eb3aaba60cd8c464837f7884521fc467285c0fc2f129b92e52bf9
>
> commons-validator-1.9.0-javadoc.jar=b4b3dee67453e72ea070140d858ff66c45ed5794b69b68760639726cea0edba1224cb2c1cda64411893ded0ba96e2758a7677e2ffa21249899630e39949d88ed
>
> commons-validator-1.9.0-sources.jar=f91890e90979ed1c7abcebb4b37f223a163bfc73bc3da6a4bc3469d399e7d0ff9315d89e528bab88b53cd0ef0a1c3f8c7e0e463a784f47546ae8ca8f3d4c2269
>
> commons-validator-1.9.0-src.tar.gz=4e36f0ec5b1b8ae9724f020c51396332444d7359988fbcceaab004cde30e223b8130315e85d9b3d568fdc30399e9e503783bb81f217fe5f846f9e14c484a1fe0
>
> commons-validator-1.9.0-src.zip=201ee0723d5f078b128aa7a54bc2b03494c467e6f2df843d74bf3607d085067a0ea395e1e2174fd3237248f18f8bc5e7469e72fc9378813cbe7e5397e20c03d1
>
> commons-validator-1.9.0-test-sources.jar=6fee6648f66e666ff49e99ef3ee49039436bd19b150eb2294d3b6a0e57dab7c0a9e7bcaecde005c478f24a21729d59365e4deb096a579b5044aafa513c90972c
>
> commons-validator-1.9.0-tests.jar=2c2a13fd3c242c1ab06e9ef8f6f18ed3eae392b8fb0a5c9bbce137ce0e9873820c37197a8517984a42d4804433501521c5f5970ef8ae868f8c6d2a061e88b05e
>
> commons-validator_commons-validator-1.9.0.spdx.json=bd19d362ae59afbe41425f57e02d4d5c32f99b9e218ebdf6ea8eaa388cb9fb28721e93781f084533e98eb345d9d7bc5a96790e06e0ac1f0d0aaff6db063042fe
>
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
>
> openjdk version "17.0.11" 2024-04-16
> OpenJDK Runtime Environment Homebrew (build 17.0.11+0)
> OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing)
>
> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> Java version: 17.0.11, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
>
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
>
> Details of changes since 1.8.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.9.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.8.0):
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/validator/1.9.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Phil Steitz]

+1

Checked build, tests, built jar, reports, release notes.  All look good.
Checked build on
Maven 3.9.3
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-120.04.1)

Phil

On Thu, Feb 29, 2024 at 3:48 PM Gary Gregory  wrote:

> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
>
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
>
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch 
> commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
>
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
>
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
>
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
>
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
>
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
>
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
>
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
>
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
>
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
>
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
>
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 2.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.11.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a1126

Re: [pool] Recovering from transient factory outages

[Phil Steitz]

> On Feb 14, 2024, at 12:24 AM, Romain Manni-Bucau  
> wrote:
> 
> Hi Phil,
> 
> You are right it can be done in pool - I'm not sure it is the right level
> (for instance in my previous example it will need to expose some
> "getCircuitBreakerState" to see if it can be used or not) but maybe I'm too
> used to decorators ;).
> The key point for [pool] is the last one, the proxying.
> Pool can't do it itself since it manages banalised instances but if you add
> the notion of proxy factory and fallback on jre proxy when it is only about
> interfaces it will work.

Thanks, that confirms that the resilient factory approach might be the way to 
go.  [pool] is interesting because so much happens in the factories and the 
lifecycle events provide natural extension points.  DBCP’s 
PoolableConnectionFactory is a great example.  I will keep playing with the 
ResilentFactory idea and see how much I can get set up generically, using DBCP 
and some of my own apps that pool other things as examples.  Patches welcome!
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
>> Le mar. 13 févr. 2024 à 22:38, Phil Steitz  a écrit :
>> 
>> Thanks, Romain, this is awesome.  I would really like to find a way to get
>> this kind of thing implemented in [pool] or via enhanced factories.  See
>> more on that below.
>> 
>> On Tue, Feb 13, 2024 at 1:27 PM Romain Manni-Bucau 
>> wrote:
>> 
>>> Hi Phil,
>>> 
>>> What I used by the past for this kind of thing was to rely on the timeout
>>> of the pool plus in the healthcheck - external to the pool - have some
>>> trigger (the simplest was "if 5 healthchecks fail without any success in
>>> between" for ex), such trigger will spawn a task (think thread even if it
>>> uses an executor but guarantee to have a place for this task) which will
>>> retry but at a faster pace (instead of every 30s it is 5 times in a run
>> for
>>> - number was tunable but 5 was my default).
>>> If still detected as down - vs not overloaded or alike - it will consider
>>> the database down and spawn a task which will retry every 30 seconds, if
>>> the database comes back - I added some business check but idea is not
>> just
>>> check the connection but the tables are accessible cause often after
>> such a
>>> downtime the db does not come at once - just destroy/recreate the pool.
>>> The destroy/recreate was handled using a DataSource proxy in front of the
>>> pool and change the delegate.
>>> 
>> 
>> It seems to me that all of this might be possible using what I was calling
>> a ReslientFactory.  The factory could implement the health-checking itself,
>> using pluggable strategies for how to check, how often, what means outage,
>> etc.  And the factory could (if so configured and in the right state)
>> bounce the pool.  I like the model of escalating concern.
>> 
>> 
>>> Indeed it is not magic inside the pool but can only better work than the
>>> pool solution cause you can integrate to your already existing checks and
>>> add more advanced checks - if you have jpa just do a fast query on any
>>> table to validate db is back for ex.
>>> At the end code is pretty simple and has another big advantage: you can
>>> circuit break the database completely while you consider the db is down
>>> just letting passing 10% of whatever ratio you want - of the requests
>> (kind
>>> of canary testing which avoids too much pressure on the pool).
>>> 
>>> I guess it was not exactly the answer you expected but think it can be a
>>> good solution and ultimately can site in a new package in dbcp or alike?
>>> 
>> 
>> I don't see anything here that is specific really to database connections
>> (other than the proxy setup to gracefully handle bounces), so I want to
>> keep thinking about how to solve the general problem by somehow enhancing
>> factories and/or pools.
>> 
>> Phil
>> 
>>> 
>>> Best,
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> ht

Re: [pool] Recovering from transient factory outages

[Phil Steitz]

Thanks, Romain, this is awesome.  I would really like to find a way to get
this kind of thing implemented in [pool] or via enhanced factories.  See
more on that below.

On Tue, Feb 13, 2024 at 1:27 PM Romain Manni-Bucau 
wrote:

> Hi Phil,
>
> What I used by the past for this kind of thing was to rely on the timeout
> of the pool plus in the healthcheck - external to the pool - have some
> trigger (the simplest was "if 5 healthchecks fail without any success in
> between" for ex), such trigger will spawn a task (think thread even if it
> uses an executor but guarantee to have a place for this task) which will
> retry but at a faster pace (instead of every 30s it is 5 times in a run for
> - number was tunable but 5 was my default).
> If still detected as down - vs not overloaded or alike - it will consider
> the database down and spawn a task which will retry every 30 seconds, if
> the database comes back - I added some business check but idea is not just
> check the connection but the tables are accessible cause often after such a
> downtime the db does not come at once - just destroy/recreate the pool.
> The destroy/recreate was handled using a DataSource proxy in front of the
> pool and change the delegate.
>

It seems to me that all of this might be possible using what I was calling
a ReslientFactory.  The factory could implement the health-checking itself,
using pluggable strategies for how to check, how often, what means outage,
etc.  And the factory could (if so configured and in the right state)
bounce the pool.  I like the model of escalating concern.


> Indeed it is not magic inside the pool but can only better work than the
> pool solution cause you can integrate to your already existing checks and
> add more advanced checks - if you have jpa just do a fast query on any
> table to validate db is back for ex.
> At the end code is pretty simple and has another big advantage: you can
> circuit break the database completely while you consider the db is down
> just letting passing 10% of whatever ratio you want - of the requests (kind
> of canary testing which avoids too much pressure on the pool).
>
> I guess it was not exactly the answer you expected but think it can be a
> good solution and ultimately can site in a new package in dbcp or alike?
>

I don't see anything here that is specific really to database connections
(other than the proxy setup to gracefully handle bounces), so I want to
keep thinking about how to solve the general problem by somehow enhancing
factories and/or pools.

Phil

>
> Best,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 13 févr. 2024 à 21:11, Phil Steitz  a
> écrit :
>
> > POOL-407 tracks a basic liveness problem that we have never been able to
> > solve:
> >
> > A factory "goes down" resulting in either failed object creation or
> failed
> > validation during the outage.  The pool has capacity to create, but the
> > factory fails to serve threads as they arrive, so they end up parked
> > waiting on the idle object pool.  After a possibly very brief
> interruption,
> > the factory heals itself (maybe a database comes back up) and the waiting
> > threads can be served, but until other threads arrive, get served and
> > return instances to the pool, the parked threads remain blocked.
> > Configuring minIdle and pool maintenance (timeBetweenEvictionRuns > 0)
> can
> > improve the situation, but running the evictor at high enough frequency
> to
> > handle every transient failure is not a great solution.
> >
> > I am stuck on how to improve this.  I have experimented with the idea of
> a
> > ResilientFactory, placing the responsibility on the factory to know when
> it
> > is down and when it comes back up and when it does, to keep calling it's
> > pool's create as long as it has take waiters and capacity; but I am not
> > sure that is the best approach.  The advantage of this is that
> > resource-specific failure and recovery-detection can be implemented.
> >
> > Another option that I have played with is to have the pool keep track of
> > factory failures and when it observes enough failures over a long enough
> > time, it starts a thread to do some kind of exponential backoff to keep
> > retrying the factory.  Once the factory comes back, the recovery thread
> > creates as many instances as it can without exceeding capacity and adds
> > them to the pool.
> >
> > I don't really like either of these.  Anyone have any better ideas?
> >
> > Phil
> >
>

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

On Tue, Feb 13, 2024 at 1:03 PM Bernd Eckenfels 
wrote:

> Phil Steitz wrote on 13. Feb 2024 20:46 (GMT +01:00):
> > Thanks, Gary.  I agree with everything below.  I think it's best to just
> > leave things as they are.
>
> If it’s plugable the project might not have to care,
> But then how to fix the reported problem? Do we have an idea what’s
> causing it?
>

At this point, my best guess is that the app is not closing connections on
some exception paths.  Given that force-killing connections that will get
killed anyway on return improves the situation supports that idea, but I
have not dug into the application code.

>
> And a extension to that, using a conn3crion pool you expect it abstracts
> and handles all
> Those idiosyncrasies of different drivers, platforms and JDBC
> interpretations. Just giving
> Up is not the best option.
>

We decided years ago that we were not going to try to add special code for
every driver and I think that is a good decision.  The code is already
plenty complex.  I think the solution implemented now to fast fail
validation in this case is sufficient.  I don't think waiting to close
until the connection is returned is actually causing the reported problem.

>
> In my experience with a properitary (but very robust pool since it handles
> a small number of drivers)
> throwing away connections on concrete suspicion turned out to be helpful.
> Either by configurable state, substrings of error messages or actual
> sqlexception subtypes.
>
> But maybe additional validation is also fine as long as it uses strict
> timeouts, some control for paralysis and starvation. If I understand this
> would happen in the mentioned problem case, so is there a timeout missing.
>
> Having said that as a tip to OP use tcpkeepalive and lower the timeouts.
> It saved my ass more than once, especially with VIPs in place.
>

The liveness problem is a [pool] concern, per my recent post.  I think
getting support in [pool] for managing transient factory outages would
really help.  Any ideas that you have on how to do that would be much
appreciated.

Phil

>
> Gruss
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[pool] Recovering from transient factory outages

[Phil Steitz]

POOL-407 tracks a basic liveness problem that we have never been able to
solve:

A factory "goes down" resulting in either failed object creation or failed
validation during the outage.  The pool has capacity to create, but the
factory fails to serve threads as they arrive, so they end up parked
waiting on the idle object pool.  After a possibly very brief interruption,
the factory heals itself (maybe a database comes back up) and the waiting
threads can be served, but until other threads arrive, get served and
return instances to the pool, the parked threads remain blocked.
Configuring minIdle and pool maintenance (timeBetweenEvictionRuns > 0) can
improve the situation, but running the evictor at high enough frequency to
handle every transient failure is not a great solution.

I am stuck on how to improve this.  I have experimented with the idea of a
ResilientFactory, placing the responsibility on the factory to know when it
is down and when it comes back up and when it does, to keep calling it's
pool's create as long as it has take waiters and capacity; but I am not
sure that is the best approach.  The advantage of this is that
resource-specific failure and recovery-detection can be implemented.

Another option that I have played with is to have the pool keep track of
factory failures and when it observes enough failures over a long enough
time, it starts a thread to do some kind of exponential backoff to keep
retrying the factory.  Once the factory comes back, the recovery thread
creates as many instances as it can without exceeding capacity and adds
them to the pool.

I don't really like either of these.  Anyone have any better ideas?

Phil

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

Thanks, Gary.  I agree with everything below.  I think it's best to just
leave things as they are.

Phil

On Mon, Feb 12, 2024 at 7:25 PM Gary Gregory  wrote:

> I've used many JDBC drivers from different vendors, FOSS and
> proprietary, and if I've learned one thing, it is that each is its own
> world within the universe of the DBMS it operates in.
>
> It is impossible to write a generic tool; they all end up providing
> plugins for DB-specific features, sure, but those plugins invariably
> also account for behavioral differences between drivers.
>
> You can't even rely on all JDBC APIs to be implemented that one would
> imagine should be "core" to the functionality.  I've seen such APIs
> just stubbed to throw exceptions. This is especially common for
> metadata-related APIs.
>
> Relying on SQL states is pretty hopeless IMO. I've had to allow custom
> configs in apps to try and figure out the driver and connection state
> from exception class names and exception message contents because you
> can't rely on SQL states, and if you do then you realize that
> different drivers use different states in similar contexts, so then
> you allow for customization of _that_ too, bleh.
>
> All of this is to say that it feels dangerous to remove any hook we
> provide.
>
> I just can't see a reliable way to detect a broken Connection unless
> it's a detectable network breakage (if a socket or IO exception is the
> root cause).
>
> The bottom line is that connections are really expensive to create,
> and should only be thrown away if you know for sure it's gone bad. I'd
> never want to throw away a connection that is fine from the server POV
> but the driver throws exception X because for whatever reason, is
> reusable, but we throw it away.
>
> HTH,
> Gary
>
> On Mon, Feb 12, 2024 at 2:42 PM Phil Steitz  wrote:
> >
> > In DBCP-595, a change is suggested to force close connections when a
> fatal
> > SQL exception has occurred.  As of Version 2.2 of DBCP, fatal exceptions
> > are tracked and the fastFailValidation property can be set to fast fail
> > validations when a fatal exception has occurred on a connection.  This
> > change would obsolete that property, as it would make the pool close the
> > connection immediately.
> >
> > I see two pros for this change and one con.
> >
> > Pros:
> > 0) Bad connection is destroyed immediately
> > 1) Works when validation is turned off
> >
> > Con:
> > Incorrect SQL states returned by drivers or transient failures may cause
> > over-zealous purging of connections.
> >
> > I vaguely recall the "Con" as the reason why we implemented
> > fastFailValidation instead of direct close on these failures, but I can't
> > find the discussion in the archives.
> >
> > Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DBCP] Support request boundaries

[Phil Steitz]

On Tue, Jan 23, 2024 at 11:35 AM Phil Steitz  wrote:

> To make it easier to follow and find later, let's move the discussion
> started in [1], [2] here.
>
> The request made in the Jira [1] and implemented in the PR [2]  to send
> beginRequest and endRequest messages to drivers seems reasonable to me, but
> just implementing unilaterally by default is probably not the best thing to
> do.
>
> Summarizing discussion so far (Gary, Bernd, meedbak, pls fix any errors):
>
> 0) The spec is vague and drivers seem to do different kinds of things or
> make different kinds of assumptions based on these messages.  There are
> some references in
> [2] .
>
> 1) There is potential to reduce the activate/passivate overhead when we
> can safely rely on these messages to maintain connection attributes.
>
> 2) It's not obvious when we should be send the messages.  Borrow and
> return are kind of obvious, but what about when a connection is idle but
> under maintenance?  Might be better to put the calls in
> PoolableConnectionFactory's activate/passivate.
>
> 3) This raises the adjacent concern that it might be good to allow PCF
> activate/passivate to be pluggable.
>
> 4) The spec has been around since 2017, but behaviors do not appear to
> have been standardized.  Making sure that what we do is safe for all
> implementations may be tricky.
>
> Based on above, the following options seem reasonable and not too
> difficult to me.
>
> a) do nothing
> b) add a configuration property that makes dbcp send the messages on
> activate/passivate or borrow/return (need to decide which)
>

After more research and listening to comments, I think this is the best
approach, with beginRequest sent on PCF activate and endRequest sent on PCF
passivate.  Using activate/passivate instead of getConnection and close on
the datasources enables us to make a single change and also prevents
conflicts with pool maintenance (testWhileIdle).

I would be happy to review a PR with tests for this if there are no
objections.

Phil


> c) add another configuration property that tells PCF to let the driver
> manage connection properties, so when used with b, fewer calls might be
> needed to manage connection properties.
>
> Options b) and c) would have to consider potential conflicts with current
> properties cacheState, enableAutoCommitOnReturn and rollbackOnReturn.
>
> Phil
>
> [1] https://issues.apache.org/jira/browse/DBCP-592
> [2] https://github.com/apache/commons-dbcp/pull/324
>
>
>
>
>

[dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

In DBCP-595, a change is suggested to force close connections when a fatal
SQL exception has occurred.  As of Version 2.2 of DBCP, fatal exceptions
are tracked and the fastFailValidation property can be set to fast fail
validations when a fatal exception has occurred on a connection.  This
change would obsolete that property, as it would make the pool close the
connection immediately.

I see two pros for this change and one con.

Pros:
0) Bad connection is destroyed immediately
1) Works when validation is turned off

Con:
Incorrect SQL states returned by drivers or transient failures may cause
over-zealous purging of connections.

I vaguely recall the "Con" as the reason why we implemented
fastFailValidation instead of direct close on these failures, but I can't
find the discussion in the archives.

Phil

[DBCP] Support request boundaries

[Phil Steitz]

To make it easier to follow and find later, let's move the discussion
started in [1], [2] here.

The request made in the Jira [1] and implemented in the PR [2]  to send
beginRequest and endRequest messages to drivers seems reasonable to me, but
just implementing unilaterally by default is probably not the best thing to
do.

Summarizing discussion so far (Gary, Bernd, meedbak, pls fix any errors):

0) The spec is vague and drivers seem to do different kinds of things or
make different kinds of assumptions based on these messages.  There are
some references in
[2] .

1) There is potential to reduce the activate/passivate overhead when we can
safely rely on these messages to maintain connection attributes.

2) It's not obvious when we should be send the messages.  Borrow and return
are kind of obvious, but what about when a connection is idle but under
maintenance?  Might be better to put the calls in
PoolableConnectionFactory's activate/passivate.

3) This raises the adjacent concern that it might be good to allow PCF
activate/passivate to be pluggable.

4) The spec has been around since 2017, but behaviors do not appear to have
been standardized.  Making sure that what we do is safe for all
implementations may be tricky.

Based on above, the following options seem reasonable and not too difficult
to me.

a) do nothing
b) add a configuration property that makes dbcp send the messages on
activate/passivate or borrow/return (need to decide which)
c) add another configuration property that tells PCF to let the driver
manage connection properties, so when used with b, fewer calls might be
needed to manage connection properties.

Options b) and c) would have to consider potential conflicts with current
properties cacheState, enableAutoCommitOnReturn and rollbackOnReturn.

Phil

[1] https://issues.apache.org/jira/browse/DBCP-592
[2] https://github.com/apache/commons-dbcp/pull/324

Re: [ALL] Standardise Maven defaultGoal in components?

[Phil Steitz]

What exactly is the point of the default goal?  I mean when is it expected to 
be used?  Automations?  Pipes of some kind?  It’s not always executed, right?  
So if I say “clean” was the default, “mvn test” would not mean “mvn clean 
test”, right?  

Phil

> On Oct 8, 2023, at 7:11 AM, sebb  wrote:
> 
> There are currently lots of variations of the defaultGoal in different
> components.
> 
> It may be sensible to establish a standard setting which components
> should adopt (unless there is a good reason to do otherwise).
> 
> If so, what should that be, and where does it get documented?
> 
> Personally, I don't think install should ever be a default goal as it
> changes the environment outside the component.
> 
> Main goals seen:
> clean
> install
> package
> site
> test
> verify
> 
> Other goals seen:
> apache-rat:check
> checkstyle:check
> clirr:check
> findbugs:check
> japicmp:cmp
> javadoc:javadoc
> pmd:check
> pmd:cpd-check
> spotbugs:check
> 
> Sebb
> 
> -
> 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: [all] stopping dependabot and security analyses on dormant components

[Phil Steitz]

On Tue, Oct 3, 2023 at 1:42 PM Emmanuel Bourg  wrote:
>
> Le 03/10/2023 à 20:18, Bruno Kinoshita a écrit :
> > Same for me, I prefer to know ahead of time if there are any issues with
> > dependencies.
>
> But the Commons components are mostly dependency-less, we are flooded by
> dependabot requests to update non code related dependencies (Maven
> plugins, GitHub actions) for non critical purposes. It would be better
> to have such notifications for CVEs only.

I also hate the noise, but I share the pay-as-you-go mentality that
Gary and Bruno express.  Shoving too many updates in the runup to the
release can make things harder and cause things to be missed.  I was
bitten badly some years back by a plugin update that caused release
jars to be borked.  I would have more likely caught it if the update
had happened sooner.   I think sebb's suggestion of decreasing check
frequency is practical.

Phil
>
> Emmanuel Bourg
>
>
> -
> 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: [ALL] pom.xml should not contain RM details

[Phil Steitz]

On Tue, Oct 3, 2023 at 1:26 AM sebb  wrote:
>
> The properties are used by the release plugin.
>
> But since they are unique to the user, they do not belong in the shared pom.

So they should be blank in the component pom?  Why do they need to be
there at all?  Can't they just be provided on the command line?  I
detest settings.xml, btw.  Not under source control, throw-back to the
old special local voodoo build days.

Phil
>
> On Tue, 3 Oct 2023 at 02:33, Phil Steitz  wrote:
> >
> > +1 but why then are those properties there?
> >
> > Phil
> >
> > > On Oct 2, 2023, at 3:58 PM, sebb  wrote:
> > >
> > > As the subject says, please do not use the pom to store RM details such 
> > > as
> > >
> > > commons.releaseManagerName
> > > commons.releaseManagerKey
> > >
> > > These properties are personal to the user, and should be defined in
> > > ~/.m2/settings.xml.
> > > See https://commons.apache.org/proper/commons-release-plugin/index.html
> > >
> > > Or you can define them on the command line.
> > >
> > > If the RM details are stored in the pom, then it is all too easy for
> > > the wrong values to be used.
> > >
> > > Thanks,
> > > Sebb
> > >
> > > -
> > > 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: [ALL] pom.xml should not contain RM details

[Phil Steitz]

+1 but why then are those properties there?

Phil

> On Oct 2, 2023, at 3:58 PM, sebb  wrote:
> 
> As the subject says, please do not use the pom to store RM details such as
> 
> commons.releaseManagerName
> commons.releaseManagerKey
> 
> These properties are personal to the user, and should be defined in
> ~/.m2/settings.xml.
> See https://commons.apache.org/proper/commons-release-plugin/index.html
> 
> Or you can define them on the command line.
> 
> If the RM details are stored in the pom, then it is all too easy for
> the wrong values to be used.
> 
> Thanks,
> Sebb
> 
> -
> 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: [site] [all] broken links

[Phil Steitz]

Thanks, Seb.  Where, btw, do the commit diffs for the site go?

Phil

On Sun, Oct 1, 2023 at 6:09 AM sebb  wrote:
>
> On Sun, 1 Oct 2023 at 13:32, Phil Steitz  wrote:
> >
> > Thanks, Sebb.  Strange that some of the links work but not others.
>
> The relative links were added to site.xml (in commons parent) earlier this 
> year.
> AFAICT only the sites built since then have the problem, because only
> they have the extra links.
>
> Found a few more I had overlooked.
>
> Also did pool, because I realised that a rebuild of the site won't
> solve the problem until commons parent is re-released.
>
> > Phil
> >
> > > On Oct 1, 2023, at 4:10 AM, sebb  wrote:
> > >
> > > I've already updated all the sites apart from pool.
> > >
> > >> On Sun, 1 Oct 2023 at 11:53, Rob Tompkins  wrote:
> > >>
> > >> Will look at this and write jira for it.
> > >> -Rob
> > >>
> > >>>> On Oct 1, 2023, at 4:52 AM, sebb  wrote:
> > >>>
> > >>> As to the other sites, there should be no need to regenerate them: one
> > >>> can just update the production sites in SVN.
> > >>> I should be able to do that a bit later.
> > >>>
> > >>>> On Sun, 1 Oct 2023 at 09:41, sebb  wrote:
> > >>>>
> > >>>> Looks like the site-relative links in
> > >>>> https://github.com/apache/commons-parent/blob/master/src/site/site.xml
> > >>>> are not working.
> > >>>>
> > >>>> Try changing the links to absolute ones.
> > >>>>
> > >>>>> On Sun, 1 Oct 2023 at 01:40, Phil Steitz  
> > >>>>> wrote:
> > >>>>>
> > >>>>> I am not sure what is causing this, but somehow the links generated 
> > >>>>> for
> > >>>>> component sites with the current parent and plugins are messed up in 
> > >>>>> the
> > >>>>> General Information section (which appears on some sites and not 
> > >>>>> others).
> > >>>>> In verifying the updated [pool] site, I see that for some reason the 
> > >>>>> links
> > >>>>> for "site publication" and the "commons release plugin" are broken.  I
> > >>>>> notice that io, dbcp and lang all have the same problem.  At first, I
> > >>>>> thought it was due to the use of relative links in the main site nav
> > >>>>> entries, but others in the same block work correctly.  Any ideas on 
> > >>>>> how to
> > >>>>> fix this?
> > >>>>>
> > >>>>> Phil
> > >>>
> > >>> -
> > >>> 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

Re: [VOTE] Release Apache Commons Net 3.10.0 based on RC1

[Phil Steitz]

Looks good to me.  I tested source tarball build with

Linux #93~20.04.1-Ubuntu SMP Wed Sep 6 16:15:40 UTC 2023 x86_64
openjdk version "1.8.0_382"
OpenJDK Runtime Environment (build 1.8.0_382-8u382-ga-1~20.04.1-b05)
OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode)
and
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed
mode, sharing)

+1

Phil

On Sun, Oct 1, 2023 at 6:48 AM Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons Net 3.9.0 was released, so I would like to release Apache
> Commons Net 3.10.0.
>
> Apache Commons Net 3.10.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1 (svn
> revision 64282)
>
> The Git tag commons-net-3.10.0-RC1 commit for this RC is
> c3f36eb9078971a159a93065389983fd60ee95f6 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=c3f36eb9078971a159a93065389983fd60ee95f6
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-net.git
> --branch 
> commons-net-3.10.0-RC1 commons-net-3.10.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1661/commons-net/commons-net/3.10.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sun Oct 01 09:35:09 EDT 2023
>
> commons-net-examples-3.10.0.jar=f39be82d6f72f551a723467ca381de363290a4ebd2f885a939ee548b4c5469353bfc4dd6e8ba5c881ded85c5d5245cb70a1940729a61c3fbae9e0bb3d822333a
>
> commons-net-3.10.0-tests.jar=75428b4d6446f98a87ec5ffd76fecc96b292a585903e57b83626c488a8ef106ad682274db9b2964aded4a5a0321abaa48342d86076d5702714c8e80698bb017d
>
> commons-net_commons-net-3.10.0.spdx.json=bc092ab2f294d55df36ca306f072ddbe956e769c99c68867ad671eec6dde5d0de3888de02daf60b4440e87275f20a7271aebfbdc528dbd9f2a6f4f1b833c545b
>
> commons-net-3.10.0-test-sources.jar=7f5e769997dbb322c476ee16df08d32c85082f7a5cb2da0dbe971414df9bc18fff9454bf273913e4f6b2ebe3c680405108c877b2f3d2f66afb746f0b30956302
>
> commons-net-3.10.0-src.zip=a29748689c64660969fab26f4c33a86114fec6c680707ac78f51c84b3b0dd5465005e24b4e8ce2112e367d7a452b77147a00bb446573613759672265ec3c1891
>
> commons-net-3.10.0-sources.jar=acb8f07ac5a1f4e3369370f8549eb0951ae340933c851daa3271e072d42c2709789d2c5f62ca138c787787a9dcec5585666ad737f80f4e7c17f0cd6eff3ce26d
>
> commons-net-3.10.0-bin.zip=42d48be13ee3945d7e1ac1dc7cb467f698fed9b87e54f9fd02e8a37d95087823dc961c385f676e7b626f12552b2950f4c965f2f5ea309917a31b3faf2c2c08e6
>
> commons-net-3.10.0-bom.xml=b42bf3ab0403d66c6fffde48fe6cafcd0b332d2b8f960bd14e0725a3ec476f968907493182bb171dafe376060fa22fd119094d8f1ceece5d8476d4316d4938cb
>
> commons-net-3.10.0-bom.json=bc2c94f269b5cee82345b3e4d23ce3f2673a6cbc8ad1e1b212aa903a7a089017f5e8f30952495b24313d8d2bcb9209048a29a00fc208d7bab3ae6b59ecf7db59
>
> commons-net-3.10.0-javadoc.jar=ade9ed8ffc50a7d01867c2c60b6abb9da2657bb022cf9e3c1f85203887451b9cde1ee975e459fbcf222366f8d84ea3e883f69c90831b8ab63cd243a80f7716ee
>
> commons-net-ftp-3.10.0.jar=251ffd3ac6d516823aa5c0cba39793db01b65c17c974f1014f8315bf7775cc60f17f0411ec14ed8fd14d62e42963487ee0500ed42cd03a19f88a2fed2dee7874
>
> commons-net-3.10.0-src.tar.gz=d9d80255feddfb434d3baa629aa9e6d8feffd530c5e3172106fec55bbc986f6423a46dc9e737a1bb7020c62447229e6b83d0b7f9582d041e1def423536cc92dd
>
> commons-net-3.10.0-bin.tar.gz=8707be9410ee8d58889c142f1bf0628445278d38e941aaef2a1be1e16757fad5c50f0ebb3e4f6603bc18955822a8fd383476d4137085e769ddec5b68326015bf
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> using:
>
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 17.0.8.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
> Darwin  23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:42
> PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
>
> Details of changes since 3.9.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1/site/index.html
> (note some *relative* links are broken and the 3.10.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 3.9.0):
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/net/3.10.0-RC1/site/rat-report.html
>
> KEYS:
>  

[ANNOUNCEMENT] Apache Commons Pool 2.12.0

[Phil Steitz]

The Apache Commons team is pleased to announce the release of
Apache Commons Pool 2.12.0.

Commons Pool provides an object-pooling API and a number of object pool
implementations.

Java 8 or above is required.

Version 2.12.0 is a maintenance release, including bug fixes and
enhancements.  This release is source and binary compatible with the prior
version, 2.11.1.  All users are encouraged to upgrade.

A complete historical list of changes to Commons Pool is available here:
https://commons.apache.org/proper/commons-pool/changes-report.html

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Pool website:
https://commons.apache.org/proper/commons-pool/

Source and binary distributions are available from the Commons Pool
download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Please verify the hashes and signatures on downloaded artifacts.

The 2.x versions of Commons Pool are distributed under the commons-pool2
maven artifactId. To pull Commons Pool 2.12.0 into an Apache Maven build as
a dependency, use


org.apache.commons
commons-pool2
2.12.0


Thanks in advance for bug reports, suggestions for improvement, patches or
other contributions to the Apache Commons community.

Phil Steitz
-Apache Commons Team

Re: [site] [all] broken links

[Phil Steitz]

Thanks, Sebb.  Strange that some of the links work but not others.

Phil

> On Oct 1, 2023, at 4:10 AM, sebb  wrote:
> 
> I've already updated all the sites apart from pool.
> 
>> On Sun, 1 Oct 2023 at 11:53, Rob Tompkins  wrote:
>> 
>> Will look at this and write jira for it.
>> -Rob
>> 
>>>> On Oct 1, 2023, at 4:52 AM, sebb  wrote:
>>> 
>>> As to the other sites, there should be no need to regenerate them: one
>>> can just update the production sites in SVN.
>>> I should be able to do that a bit later.
>>> 
>>>> On Sun, 1 Oct 2023 at 09:41, sebb  wrote:
>>>> 
>>>> Looks like the site-relative links in
>>>> https://github.com/apache/commons-parent/blob/master/src/site/site.xml
>>>> are not working.
>>>> 
>>>> Try changing the links to absolute ones.
>>>> 
>>>>> On Sun, 1 Oct 2023 at 01:40, Phil Steitz  wrote:
>>>>> 
>>>>> I am not sure what is causing this, but somehow the links generated for
>>>>> component sites with the current parent and plugins are messed up in the
>>>>> General Information section (which appears on some sites and not others).
>>>>> In verifying the updated [pool] site, I see that for some reason the links
>>>>> for "site publication" and the "commons release plugin" are broken.  I
>>>>> notice that io, dbcp and lang all have the same problem.  At first, I
>>>>> thought it was due to the use of relative links in the main site nav
>>>>> entries, but others in the same block work correctly.  Any ideas on how to
>>>>> fix this?
>>>>> 
>>>>> Phil
>>> 
>>> -
>>> 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

[site] [all] broken links

[Phil Steitz]

I am not sure what is causing this, but somehow the links generated for
component sites with the current parent and plugins are messed up in the
General Information section (which appears on some sites and not others).
In verifying the updated [pool] site, I see that for some reason the links
for "site publication" and the "commons release plugin" are broken.  I
notice that io, dbcp and lang all have the same problem.  At first, I
thought it was due to the use of relative links in the main site nav
entries, but others in the same block work correctly.  Any ideas on how to
fix this?

Phil

[VOTE] [RESULT] Release Apache Commons Pool 2.12.0 based on RC5

[Phil Steitz]

This vote has passed with binding +1 votes from

Bruno Kinoshita
Gary Gregory
Rob Tompkins
Phil Steitz

and no other votes.

Thanks to all who reviewed the release candidate.

Phil


On Tue, Sep 26, 2023 at 12:50 PM Phil Steitz  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Pool 2.11.1 was released, so I would like to release
> Apache Commons Pool 2.12.0.
>
> Apache Commons Pool 2.12.0 RC5 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5 (svn
> revision 64211)
>
> The Git tag commons-pool-2.12.0-RC5 commit for this RC is
> commons-pool-1.12.0-RC5 which you can browse here:
>
> https://github.com/apache/commons-pool/releases/tag/commons-pool-2.12.0-RC5
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-pool.git
> --branch commons-pool-2.12.0-RC5 commons-pool-2.12.0-RC5
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1659/org/apache/commons/commons-pool2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Sep 26 11:50:36 MST 2023
>
> commons-pool2-2.12.0-bom.xml=46f6d5da5c530b482bf3d23d53c337f28507d9d27b5f4ef56dc3523fe27c24833de0e05d20460a1c0b77dd5569f1d1207e9d95bbf5332ae103503abf00a0bdfb
>
> commons-pool2-2.12.0-bin.zip=08ea2579002276e6e5ff576bd3cfc1b4b29e1ecd471c6a38b263f57c9a887a158eee62a6ff3093e6017cb947409194dd1d7a9d681ae32588eb241404da3796e0
>
> commons-pool2-2.12.0-tests.jar=697ac4c33eca5067dedfbc6b7f656aa230ba71908aed6450ca49a0419aad0f588bd0a238c9e7198999265b79c7fab2e760f3575bdad7ff13109ef2aaf72c36a4
>
> commons-pool2-2.12.0-sources.jar=470d45652b9c63e92feb26c517edfd324878214a87faeee79e70772fd6ead1553aaa362b209dc1cb950cc144004223b186e142810a72be0caa839e87446999b6
>
> commons-pool2-2.12.0-src.zip=c09424e2a6209adf0e1660de421c35c3b80c395a5d4ef30e6ff58c499b5768cde15e508f858dffc0dfde1c9a3d18d5d7681d67ca5c796d99e5922c712889e195
>
> commons-pool2-2.12.0-bom.json=f2ac923db32811d691c304ab8425fff757ebe3102cbacafad7244dc3f5d742e1376ba7fb906b177a626dd766f49baa2da977efb260e3d66aa8dd8b3034954276
>
> org.apache.commons_commons-pool2-2.12.0.spdx.json=2e8e3f1f2aa69abc7c49b0487960159cf6690e5de4ad74706c47e00f55479490b7ed31a478b82f6b51c94ef23501fc8850432d00d7364180bba5486d63cd33bc
>
> commons-pool2-2.12.0-src.tar.gz=fefb22459519b92712a9e5178099d19cc7fc8a5b07f633387c11f5b30d86ae8f73e237728be08a2705cf56f986be5a51c11a084b01224e5a0c9ccf7b34dc6258
>
> commons-pool2-2.12.0-javadoc.jar=a4b3df904311892327d210f0c507b4c9cba1e2289071a87d873ea72f60052a5658728f6412715c6e1cb0528f8df15cd9c74fe20d173b17cc887120048334a119
>
> commons-pool2-2.12.0-test-sources.jar=b93d6529527029f26aa51bf451e2c0250e5e20c7c884b51d2c1377d3e58c218679ba56f87e10bd1062fbc87bb8db3a2bfe98c5b54910566a57260ab77f530482
>
> commons-pool2-2.12.0-bin.tar.gz=3d75b997287df339acfd76662cf6e4b645b10fff825bffc58dd2238dbaaccf7b81c61aa59ada6f667a3f29d9db0730e34b25526f7d309db36361e4d1e8c6ec70
>
> I have tested the build of this release candidate with
>
> mvn clean package site
> under
> openjdk version "17.0.8.1" 2023-08-24
> OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04)
> OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed
> mode, sharing)
>
> openjdk version "11.0.20.1" 2023-08-24
> OpenJDK Runtime Environment (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04)
> OpenJDK 64-Bit Server VM (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04,
> mixed mode, sharing)
>
> openjdk version "1.8.0_382"
> OpenJDK Runtime Environment (build 1.8.0_382-8u382-ga-1~20.04.1-b05)
> OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode)
>
> Using
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
> Linux 5.15.0-83-generic #92~20.04.1-Ubuntu SMP
>
> And
> openjdk version "20.0.1" 2023-04-18
> OpenJDK Runtime Environment Homebrew (build 20.0.1)
> OpenJDK 64-Bit Server VM Homebrew (build 20.0.1, mixed mode, sharing)
> Darwin Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT 2023;
> root:xnu-8796.141.3~6/RELEASE_X86_64
>
> I have also tested the compiled jar against DBCP 2.10 and run soak and
> performance tests using Commons Performance.  Performance was not
> significantly different from earlier 2.x versions for the tested workloads.
>
> Details of changes since 2.11.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/index.html
> (note some *relative* links are broken and

Re: [VOTE] Release Apache Commons IO 2.14.0 based on RC1

[Phil Steitz]

After carefully reviewing the Spotbugs report, I am going to change my vote
to

+1

Most of the complaints are about returning references vs copies of things
in getters.  The SA_LOCAL_SELF_COMPARISON complaint looks legit, but
probably harmless because it appears to have been there for a long time.
It is basically dead code - comparing references vs buffer contents, which
it looks like it is intended to do.  The errors in the report should be
fixed or filtered, but I don't think any of them are show-stoppers for
release.

Phil

On Tue, Sep 26, 2023 at 9:38 AM Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons IO 2.13.0 was released, so I would like to release Apache
> Commons IO 2.14.0.
>
> Apache Commons IO 2.14.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1 (svn
> revision 64208)
>
> The Git tag commons-io-2.14.0-RC1 commit for this RC is
> 82250a879112e9b58c58d289e166d66942d77341 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=82250a879112e9b58c58d289e166d66942d77341
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-io.git
> --branch commons-io-2.14.0-RC1 commons-io-2.14.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1657/commons-io/commons-io/2.14.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Sep 25 06:51:48 EDT 2023
>
> commons-io-2.14.0-sources.jar=cb32b6c6b6c875633103e248c7998c8a0082c0c4d476688897a16549573b4d53e63fec4255f100521f265bf58b16cb4f4b7e09f4ce4b2f086eb13a15b9cce539
>
> commons-io-2.14.0-bin.zip=f80efb25e30d89fe9ea26fc85baa3666c1c69c3bcdda6d566e9e95d1c627c52a16582ed48f13a06bf4d89e49e14dc1f19608f32e6dbaecd66725acc2d58d720d
>
> commons-io-2.14.0-src.tar.gz=f96568e55dec789661c02a1f9455bf30eece5b621f99258385112d39aded37b1ec3dea93275d3ccaed9590e9cf95ae4958ef9d028db4275900180e269c9db970
>
> commons-io-2.14.0-src.zip=d6a469218279bb9be92caa43eaf49478ecc5d90056677c504c2d16f2f44677baf0929c01c2c096d18b99158d641ef5a6dcba44b88076db0f062746afa684ca5d
>
> commons-io-2.14.0-bom.json=9eb19600b17cfaa68d0e52f1986f09802f8bfea7a031eff536249fcca18e47bc25144b60187158ef0e8f80adeae4ae8c9b10925b6995b1e0191aa76ecf550e7a
>
> commons-io-2.14.0-tests.jar=4692a6fc8b11b8c0f60b0896cdc1a3a8bb5f0710e8a47c4589aa0bffe683b31fb512743af03ac699f639c2bb55342bd6c833c5dac52dcf6b0f68a8e3e9ff1d21
>
> commons-io-2.14.0-test-sources.jar=ccefebb9113638343d15e05f1e25442e4cbc201ae8c6b07bc52c1ba3cdb069fda98418aa6f2731895012b76cc0fa21eb4599220dd6c9d4f9386c8b1fc27e99d3
>
> commons-io_commons-io-2.14.0.spdx.json=1e509681b8e883ed500ba2c349fed3d3527e6a69101fa0f7b305e5b2f4b12bcbe67869dbefc5e26d66875b6161fab8a2747a87c553e40da1902e9ed1b6e306e8
>
> commons-io-2.14.0-bin.tar.gz=a15eb43dede3c82895fe0411963ce2ba7b75716378dd93aa02f68f909f8777fdba8d738d7f895e7c4d6931bf0bba18fd409b5f6c7e0f02452047ac71f8dba313
>
> commons-io-2.14.0-javadoc.jar=24ed778593714a8eb200d2daa235ca755f9c8cf06d8b1c0b164df72049b1706d3827bf9ba772297334aa3ff1833f6257249c1bcdb66e4e9e3f6874cd58a1e212
>
> commons-io-2.14.0-bom.xml=256580d4b1ef0d6fce4d9379e87d62a05ca1f954abd6864406023800b5679067f50c33d8139dd830a55b016abffa6d8cba97d4f7bb06bae1f4a0307c0fec046a
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> Using:
>
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 17.0.8.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.5.2", arch: "x86_64", family: "mac"
> Darwin gdg-mac-mini.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul
>  5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64
>
> Details of changes since 2.13.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.14.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a relea

Re: [VOTE] Release Apache Commons IO 2.14.0 based on RC1

[Phil Steitz]

Build from unpacked source distro works fine under

Linux 5.15.0-83-generic #92~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023
x86_64 x86_64 GNU/Linux
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed
mode, sharing)
and
openjdk version "1.8.0_382"
OpenJDK Runtime Environment (build 1.8.0_382-8u382-ga-1~20.04.1-b05)
OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode)

sigs and hashes are good.

There are a bunch of errors reported by SpotBugs.  Doing some comparative
shopping, it looks like some (all?) of these are present in the current
release version. These should be filtered or commented.

+0

Phil

On Tue, Sep 26, 2023 at 1:26 PM Rob Tompkins  wrote:

> +1
>
> Builds successfully on all LTE java versions
> Reports look good,
> Rat Looks good,
> Signatures all check out.
>
> Cheers,
> -ROb :-p
>
> > On Sep 26, 2023, at 12:37 PM, Gary Gregory 
> wrote:
> >
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons IO 2.13.0 was released, so I would like to release Apache
> > Commons IO 2.14.0.
> >
> > Apache Commons IO 2.14.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1 (svn
> > revision 64208)
> >
> > The Git tag commons-io-2.14.0-RC1 commit for this RC is
> > 82250a879112e9b58c58d289e166d66942d77341 which you can browse here:
> >
> https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=82250a879112e9b58c58d289e166d66942d77341
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-io.git
> > --branch commons-io-2.14.0-RC1 commons-io-2.14.0-RC1
> >
> > Maven artifacts are here:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1657/commons-io/commons-io/2.14.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Mon Sep 25 06:51:48 EDT 2023
> >
> commons-io-2.14.0-sources.jar=cb32b6c6b6c875633103e248c7998c8a0082c0c4d476688897a16549573b4d53e63fec4255f100521f265bf58b16cb4f4b7e09f4ce4b2f086eb13a15b9cce539
> >
> commons-io-2.14.0-bin.zip=f80efb25e30d89fe9ea26fc85baa3666c1c69c3bcdda6d566e9e95d1c627c52a16582ed48f13a06bf4d89e49e14dc1f19608f32e6dbaecd66725acc2d58d720d
> >
> commons-io-2.14.0-src.tar.gz=f96568e55dec789661c02a1f9455bf30eece5b621f99258385112d39aded37b1ec3dea93275d3ccaed9590e9cf95ae4958ef9d028db4275900180e269c9db970
> >
> commons-io-2.14.0-src.zip=d6a469218279bb9be92caa43eaf49478ecc5d90056677c504c2d16f2f44677baf0929c01c2c096d18b99158d641ef5a6dcba44b88076db0f062746afa684ca5d
> >
> commons-io-2.14.0-bom.json=9eb19600b17cfaa68d0e52f1986f09802f8bfea7a031eff536249fcca18e47bc25144b60187158ef0e8f80adeae4ae8c9b10925b6995b1e0191aa76ecf550e7a
> >
> commons-io-2.14.0-tests.jar=4692a6fc8b11b8c0f60b0896cdc1a3a8bb5f0710e8a47c4589aa0bffe683b31fb512743af03ac699f639c2bb55342bd6c833c5dac52dcf6b0f68a8e3e9ff1d21
> >
> commons-io-2.14.0-test-sources.jar=ccefebb9113638343d15e05f1e25442e4cbc201ae8c6b07bc52c1ba3cdb069fda98418aa6f2731895012b76cc0fa21eb4599220dd6c9d4f9386c8b1fc27e99d3
> >
> commons-io_commons-io-2.14.0.spdx.json=1e509681b8e883ed500ba2c349fed3d3527e6a69101fa0f7b305e5b2f4b12bcbe67869dbefc5e26d66875b6161fab8a2747a87c553e40da1902e9ed1b6e306e8
> >
> commons-io-2.14.0-bin.tar.gz=a15eb43dede3c82895fe0411963ce2ba7b75716378dd93aa02f68f909f8777fdba8d738d7f895e7c4d6931bf0bba18fd409b5f6c7e0f02452047ac71f8dba313
> >
> commons-io-2.14.0-javadoc.jar=24ed778593714a8eb200d2daa235ca755f9c8cf06d8b1c0b164df72049b1706d3827bf9ba772297334aa3ff1833f6257249c1bcdb66e4e9e3f6874cd58a1e212
> >
> commons-io-2.14.0-bom.xml=256580d4b1ef0d6fce4d9379e87d62a05ca1f954abd6864406023800b5679067f50c33d8139dd830a55b016abffa6d8cba97d4f7bb06bae1f4a0307c0fec046a
> >
> > I have tested this with:
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
> >
> > Using:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> > Java version: 17.0.8.1, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.5.2", arch: "x86_64", family: "mac"
> > Darwin gdg-mac-mini.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul
> > 5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64
> >
> > Details of changes since 2.13.0 are in the release notes:
> >
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/RELEASE-NOTES.txt
> >
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/site/changes-report.html
> >
> > Site:
> >
> https://dist.apache.org/repos/dist/dev/commons/io/2.14.0-RC1/site/index.html
> >(note some *relative* links are broken and the 2.14.0 directories
> > are not yet created - these will be OK once the site is deplo

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC5

[Phil Steitz]

Here is my +1, based on testing in the VOTE mail.

Phil

On Tue, Sep 26, 2023 at 12:50 PM Phil Steitz  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Pool 2.11.1 was released, so I would like to release
> Apache Commons Pool 2.12.0.
>
> Apache Commons Pool 2.12.0 RC5 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5 (svn
> revision 64211)
>
> The Git tag commons-pool-2.12.0-RC5 commit for this RC is
> commons-pool-1.12.0-RC5 which you can browse here:
>
> https://github.com/apache/commons-pool/releases/tag/commons-pool-2.12.0-RC5
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-pool.git
> --branch commons-pool-2.12.0-RC5 commons-pool-2.12.0-RC5
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1659/org/apache/commons/commons-pool2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Sep 26 11:50:36 MST 2023
>
> commons-pool2-2.12.0-bom.xml=46f6d5da5c530b482bf3d23d53c337f28507d9d27b5f4ef56dc3523fe27c24833de0e05d20460a1c0b77dd5569f1d1207e9d95bbf5332ae103503abf00a0bdfb
>
> commons-pool2-2.12.0-bin.zip=08ea2579002276e6e5ff576bd3cfc1b4b29e1ecd471c6a38b263f57c9a887a158eee62a6ff3093e6017cb947409194dd1d7a9d681ae32588eb241404da3796e0
>
> commons-pool2-2.12.0-tests.jar=697ac4c33eca5067dedfbc6b7f656aa230ba71908aed6450ca49a0419aad0f588bd0a238c9e7198999265b79c7fab2e760f3575bdad7ff13109ef2aaf72c36a4
>
> commons-pool2-2.12.0-sources.jar=470d45652b9c63e92feb26c517edfd324878214a87faeee79e70772fd6ead1553aaa362b209dc1cb950cc144004223b186e142810a72be0caa839e87446999b6
>
> commons-pool2-2.12.0-src.zip=c09424e2a6209adf0e1660de421c35c3b80c395a5d4ef30e6ff58c499b5768cde15e508f858dffc0dfde1c9a3d18d5d7681d67ca5c796d99e5922c712889e195
>
> commons-pool2-2.12.0-bom.json=f2ac923db32811d691c304ab8425fff757ebe3102cbacafad7244dc3f5d742e1376ba7fb906b177a626dd766f49baa2da977efb260e3d66aa8dd8b3034954276
>
> org.apache.commons_commons-pool2-2.12.0.spdx.json=2e8e3f1f2aa69abc7c49b0487960159cf6690e5de4ad74706c47e00f55479490b7ed31a478b82f6b51c94ef23501fc8850432d00d7364180bba5486d63cd33bc
>
> commons-pool2-2.12.0-src.tar.gz=fefb22459519b92712a9e5178099d19cc7fc8a5b07f633387c11f5b30d86ae8f73e237728be08a2705cf56f986be5a51c11a084b01224e5a0c9ccf7b34dc6258
>
> commons-pool2-2.12.0-javadoc.jar=a4b3df904311892327d210f0c507b4c9cba1e2289071a87d873ea72f60052a5658728f6412715c6e1cb0528f8df15cd9c74fe20d173b17cc887120048334a119
>
> commons-pool2-2.12.0-test-sources.jar=b93d6529527029f26aa51bf451e2c0250e5e20c7c884b51d2c1377d3e58c218679ba56f87e10bd1062fbc87bb8db3a2bfe98c5b54910566a57260ab77f530482
>
> commons-pool2-2.12.0-bin.tar.gz=3d75b997287df339acfd76662cf6e4b645b10fff825bffc58dd2238dbaaccf7b81c61aa59ada6f667a3f29d9db0730e34b25526f7d309db36361e4d1e8c6ec70
>
> I have tested the build of this release candidate with
>
> mvn clean package site
> under
> openjdk version "17.0.8.1" 2023-08-24
> OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04)
> OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed
> mode, sharing)
>
> openjdk version "11.0.20.1" 2023-08-24
> OpenJDK Runtime Environment (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04)
> OpenJDK 64-Bit Server VM (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04,
> mixed mode, sharing)
>
> openjdk version "1.8.0_382"
> OpenJDK Runtime Environment (build 1.8.0_382-8u382-ga-1~20.04.1-b05)
> OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode)
>
> Using
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
> Linux 5.15.0-83-generic #92~20.04.1-Ubuntu SMP
>
> And
> openjdk version "20.0.1" 2023-04-18
> OpenJDK Runtime Environment Homebrew (build 20.0.1)
> OpenJDK 64-Bit Server VM Homebrew (build 20.0.1, mixed mode, sharing)
> Darwin Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT 2023;
> root:xnu-8796.141.3~6/RELEASE_X86_64
>
> I have also tested the compiled jar against DBCP 2.10 and run soak and
> performance tests using Commons Performance.  Performance was not
> significantly different from earlier 2.x versions for the tested workloads.
>
> Details of changes since 2.11.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared

[VOTE] Release Apache Commons Pool 2.12.0 based on RC5

[Phil Steitz]

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Pool 2.11.1 was released, so I would like to release
Apache Commons Pool 2.12.0.

Apache Commons Pool 2.12.0 RC5 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5 (svn
revision 64211)

The Git tag commons-pool-2.12.0-RC5 commit for this RC is
commons-pool-1.12.0-RC5 which you can browse here:

https://github.com/apache/commons-pool/releases/tag/commons-pool-2.12.0-RC5
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-pool.git --branch
commons-pool-2.12.0-RC5 commons-pool-2.12.0-RC5

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1659/org/apache/commons/commons-pool2/2.12.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Tue Sep 26 11:50:36 MST 2023
commons-pool2-2.12.0-bom.xml=46f6d5da5c530b482bf3d23d53c337f28507d9d27b5f4ef56dc3523fe27c24833de0e05d20460a1c0b77dd5569f1d1207e9d95bbf5332ae103503abf00a0bdfb
commons-pool2-2.12.0-bin.zip=08ea2579002276e6e5ff576bd3cfc1b4b29e1ecd471c6a38b263f57c9a887a158eee62a6ff3093e6017cb947409194dd1d7a9d681ae32588eb241404da3796e0
commons-pool2-2.12.0-tests.jar=697ac4c33eca5067dedfbc6b7f656aa230ba71908aed6450ca49a0419aad0f588bd0a238c9e7198999265b79c7fab2e760f3575bdad7ff13109ef2aaf72c36a4
commons-pool2-2.12.0-sources.jar=470d45652b9c63e92feb26c517edfd324878214a87faeee79e70772fd6ead1553aaa362b209dc1cb950cc144004223b186e142810a72be0caa839e87446999b6
commons-pool2-2.12.0-src.zip=c09424e2a6209adf0e1660de421c35c3b80c395a5d4ef30e6ff58c499b5768cde15e508f858dffc0dfde1c9a3d18d5d7681d67ca5c796d99e5922c712889e195
commons-pool2-2.12.0-bom.json=f2ac923db32811d691c304ab8425fff757ebe3102cbacafad7244dc3f5d742e1376ba7fb906b177a626dd766f49baa2da977efb260e3d66aa8dd8b3034954276
org.apache.commons_commons-pool2-2.12.0.spdx.json=2e8e3f1f2aa69abc7c49b0487960159cf6690e5de4ad74706c47e00f55479490b7ed31a478b82f6b51c94ef23501fc8850432d00d7364180bba5486d63cd33bc
commons-pool2-2.12.0-src.tar.gz=fefb22459519b92712a9e5178099d19cc7fc8a5b07f633387c11f5b30d86ae8f73e237728be08a2705cf56f986be5a51c11a084b01224e5a0c9ccf7b34dc6258
commons-pool2-2.12.0-javadoc.jar=a4b3df904311892327d210f0c507b4c9cba1e2289071a87d873ea72f60052a5658728f6412715c6e1cb0528f8df15cd9c74fe20d173b17cc887120048334a119
commons-pool2-2.12.0-test-sources.jar=b93d6529527029f26aa51bf451e2c0250e5e20c7c884b51d2c1377d3e58c218679ba56f87e10bd1062fbc87bb8db3a2bfe98c5b54910566a57260ab77f530482
commons-pool2-2.12.0-bin.tar.gz=3d75b997287df339acfd76662cf6e4b645b10fff825bffc58dd2238dbaaccf7b81c61aa59ada6f667a3f29d9db0730e34b25526f7d309db36361e4d1e8c6ec70

I have tested the build of this release candidate with

mvn clean package site
under
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu120.04, mixed
mode, sharing)

openjdk version "11.0.20.1" 2023-08-24
OpenJDK Runtime Environment (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 11.0.20.1+1-post-Ubuntu-0ubuntu120.04,
mixed mode, sharing)

openjdk version "1.8.0_382"
OpenJDK Runtime Environment (build 1.8.0_382-8u382-ga-1~20.04.1-b05)
OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode)

Using
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Linux 5.15.0-83-generic #92~20.04.1-Ubuntu SMP

And
openjdk version "20.0.1" 2023-04-18
OpenJDK Runtime Environment Homebrew (build 20.0.1)
OpenJDK 64-Bit Server VM Homebrew (build 20.0.1, mixed mode, sharing)
Darwin Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT 2023;
root:xnu-8796.141.3~6/RELEASE_X86_64

I have also tested the compiled jar against DBCP 2.10 and run soak and
performance tests using Commons Performance.  Performance was not
significantly different from earlier 2.x versions for the tested workloads.

Details of changes since 2.11.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/index.html
(note some *relative* links are broken and the 2.12.0 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.11.1):

https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC5/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!
Phil Steitz,
Release Manager (using key 4E2DDD47E19863BB87211544CD30

Re: [commons-pool] annotated tag commons-pool2-2.12.0-rc2 updated (ed218a61 -> 2abd33d4)

[Phil Steitz]

But then looking at git itself, I don't see any mod to the old tag and the
new one looks OK.

Phil

On Fri, Sep 22, 2023 at 2:47 PM Phil Steitz  wrote:

> This does not look good.  I was following instructions in [1].  I just did
> git tag -s commons-pool2-2.12.0-rc2 -m "Tag Commons Pool release 2.12.0
> RC2"
>
> I don't think that tag already existed.  Somehow it seems to have updated
> a 2.11.1 tag.  Any suggestions on how to fix this?
>
> Phil
>
> [1]
> https://svn.apache.org/repos/infra/websites/production/commons/content/releases/prepare.html
>
>
> On Fri, Sep 22, 2023 at 2:39 PM  wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> psteitz pushed a change to annotated tag commons-pool2-2.12.0-rc2
>> in repository https://gitbox.apache.org/repos/asf/commons-pool.git
>>
>>
>> *** WARNING: tag commons-pool2-2.12.0-rc2 was modified! ***
>>
>> from ed218a61 (commit)
>>   to 2abd33d4 (tag)
>>  tagging ed218a61eaf2753dcd7aafbf050558b0a3550768 (commit)
>>  replaces rel/commons-pool-2.11.1
>>   by Phil Steitz
>>   on Fri Sep 22 14:38:28 2023 -0700
>>
>> - Log -
>> Tag Commons Pool release 2.12.0 RC2
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>>
>> iF0EABECAB0WIQROLd1H4Zhju4chFUTNMDj+8H1WfgUCZQ4JVAAKCRDNMDj+8H1W
>> fsCCAKCEuM/XzhGmu0hEVUgbPDya35eYoQCgmm310/yiLwKxE712XMtn6k66t68=
>> =hhDZ
>> -END PGP SIGNATURE-
>> ---
>>
>>
>> No new revisions were added by this update.
>>
>> Summary of changes:
>>
>>

Re: [commons-pool] annotated tag commons-pool2-2.12.0-rc2 updated (ed218a61 -> 2abd33d4)

[Phil Steitz]

This does not look good.  I was following instructions in [1].  I just did
git tag -s commons-pool2-2.12.0-rc2 -m "Tag Commons Pool release 2.12.0 RC2"

I don't think that tag already existed.  Somehow it seems to have updated a
2.11.1 tag.  Any suggestions on how to fix this?

Phil

[1]
https://svn.apache.org/repos/infra/websites/production/commons/content/releases/prepare.html


On Fri, Sep 22, 2023 at 2:39 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> psteitz pushed a change to annotated tag commons-pool2-2.12.0-rc2
> in repository https://gitbox.apache.org/repos/asf/commons-pool.git
>
>
> *** WARNING: tag commons-pool2-2.12.0-rc2 was modified! ***
>
> from ed218a61 (commit)
>   to 2abd33d4 (tag)
>  tagging ed218a61eaf2753dcd7aafbf050558b0a3550768 (commit)
>  replaces rel/commons-pool-2.11.1
>   by Phil Steitz
>   on Fri Sep 22 14:38:28 2023 -0700
>
> - Log -
> Tag Commons Pool release 2.12.0 RC2
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iF0EABECAB0WIQROLd1H4Zhju4chFUTNMDj+8H1WfgUCZQ4JVAAKCRDNMDj+8H1W
> fsCCAKCEuM/XzhGmu0hEVUgbPDya35eYoQCgmm310/yiLwKxE712XMtn6k66t68=
> =hhDZ
> -END PGP SIGNATURE-
> ---
>
>
> No new revisions were added by this update.
>
> Summary of changes:
>
>

Re: [pool] RC time

[Phil Steitz]

Thanks, all.  Looks like the web site docs are way out of date as they
still refer to svn for sources.  But based on Gilles' pointer (thanks!) it
looks like we are still using svn pub-sub to deploy artifacts.  The old
scripts that I used to use may still actually work with slight mods, so I
am going to start there.  I am not sure how to publish changes to either
the component or Commons web site though, since I am pretty sure the old
CMS is no longer operating.  It looks like we are now just locally
generating sites and (svn) committing directly to
https://svn.apache.org/repos/infra/websites/production/commons/content.  Is
that right?

Phil

On Sun, Sep 17, 2023 at 7:21 AM Gary Gregory  wrote:

> If the sh files in https://github.com/apache/commons-pool/tree/POOL_1_X
> are
> no longer relevant we should remove them.
>
> Gary
>
> On Sun, Sep 17, 2023, 9:46 AM Eric Bresie  wrote:
>
> > Which indicates:
> >
> > "This document is meant as a step-by-step recipe to achieve the release
> of
> > the Commons RNG component. Note that more general instructions valid
> > for all components, including [rng], are available on the Apache Commons
> > main site: at *"https://commons.apache.org/releases/prepare.html
> > <https://commons.apache.org/releases/prepare.html>"* and
> > *"https://commons.apache.org/releases/release.html
> > <https://commons.apache.org/releases/release.html>"*
> >
> >
> > Eric Bresie
> > ebre...@gmail.com
> >
> >
> > On Sat, Sep 16, 2023 at 7:32 PM Gilles Sadowski 
> > wrote:
> >
> > > Le sam. 16 sept. 2023 à 23:54, Phil Steitz  a
> > > écrit :
> > > >
> > > > It has been quite a few years since I cut a Commons release, but I
> > would
> > > > like to step up for pool 2.12.  I think the code in the 2_X branch is
> > > > ready.  All of my soak tests and tests with my own apps and dbcp
> > > passed.  I
> > > > am sure a lot has changed since I last did this.  Is there a
> checklist
> > or
> > > > instructions somewhere?
> > >
> > >
> > >
> >
> https://github.com/apache/commons-rng/blob/master/doc/release/release.howto.txt
> > >
> > > >
> > > > Phil
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

[pool] RC time

[Phil Steitz]

It has been quite a few years since I cut a Commons release, but I would
like to step up for pool 2.12.  I think the code in the 2_X branch is
ready.  All of my soak tests and tests with my own apps and dbcp passed.  I
am sure a lot has changed since I last did this.  Is there a checklist or
instructions somewhere?

Phil

Re: [pool] 2.12.0 update

[Phil Steitz]

Well, now I really do need to apologize.  I looked carefully again at the
japicmp report and now agree that it is best to leave things as they are.
I don't think it is likely we will change the names again and this is what
deprecations are for.  So as far as I am concerned, things are good to go.
I will continue testing (including with the new DBCP release) and encourage
others to review the code and test their apps as well; but I don't think
any more changes are needed to the code in the 2_X branch now.

Phil

On Sat, Sep 9, 2023 at 3:40 PM Gary Gregory  wrote:

> Thanks for the update, no need to apologize :-)
>
> Gary
>
> On Sat, Sep 9, 2023, 6:31 PM Phil Steitz  wrote:
>
> > Sorry I got busy.  I will they to get final changes in tomorrow or
> > convince myself it is ok to release without them.  Apologies for the
> delay
> >
> > > On Sep 9, 2023, at 6:41 AM, Gary Gregory 
> wrote:
> > >
> > > Hi Phil,
> > >
> > > Where are we on a 2.12.0 release candidate?
> > >
> > > Gary
> > >
> > >> On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz 
> > wrote:
> > >>
> > >> OK, I found the source of the performance hit.  In the POOL-411
> > changes, we
> > >> had inadvertently forced every register to acquire a write lock from
> the
> > >> keylock.  I think I also finally definitively fixed the root issue
> > there.
> > >> The tricky bit about the numInterested tracking is that the counters
> are
> > >> attached to the ObjectDeques, which can be replaced.  If this happens
> > while
> > >> waiting for a write lock in either register or deregister, the code
> can
> > end
> > >> up updating the counter on a pool that has been replaced.  I added
> > checks
> > >> to trap deregistration of a null pool (should never happen) and
> followed
> > >> Sebb's suggestion to add a check for numInterested going negative.
> The
> > >> accounting setup is very efficient, but tricky to maintain.  For 3.0,
> we
> > >> might consider moving numInterested tracking to a hashmap.  For 2.x, I
> > >> think the setup is fixed now and performance is the same as earlier
> > >> versions.  Soak tests look good.
> > >>
> > >> One last thing I would like to do before we cut 2.12.0:
> > >>
> > >> We are going to be making incompatible changes in 3.0 and I don't
> think
> > we
> > >> need to telegraph all of the API changes via deprecations in 2.x -
> most
> > >> notably the recent method name changes of the form s/Time/Duration.  I
> > >> understand the rationale for these changes, but they make the 2.x code
> > very
> > >> messy with double deprecations - first from the "millis" methods and
> > then
> > >> from "Time" to "Duration."  I think it would be better to keep the
> > existing
> > >> deprecations for the "millis" methods, but drop the new "Duration"
> ones
> > and
> > >> remove deprecations for the ones they replace.  I can see the argument
> > that
> > >> it is better to tell users now, but that takes away flexibility in 3.0
> > and
> > >> makes the API look very confusing with so many methods that do the
> same
> > >> thing.  Any objections ?
> > >>
> > >> Phil
> > >>
> > >>> On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz 
> > wrote:
> > >>>
> > >>> I have run my first round of soak and performance tests on what is
> now
> > in
> > >>> the 2.x branch.  Good news is the code looks stable.  Not so good
> news
> > is
> > >>> it appears that GKOP performance has taken a material hit vs 2.11 and
> > >>> earlier versions.  I need to confirm this via more targeted tests and
> > if it
> > >>> turns out not to be real, figure out what is causing it.  Hopefully I
> > will
> > >>> get to this done in the next few days.
> > >>>
> > >>> Phil
> > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [pool] 2.12.0 update

[Phil Steitz]

Sorry I got busy.  I will they to get final changes in tomorrow or convince 
myself it is ok to release without them.  Apologies for the delay

> On Sep 9, 2023, at 6:41 AM, Gary Gregory  wrote:
> 
> Hi Phil,
> 
> Where are we on a 2.12.0 release candidate?
> 
> Gary
> 
>> On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz  wrote:
>> 
>> OK, I found the source of the performance hit.  In the POOL-411 changes, we
>> had inadvertently forced every register to acquire a write lock from the
>> keylock.  I think I also finally definitively fixed the root issue there.
>> The tricky bit about the numInterested tracking is that the counters are
>> attached to the ObjectDeques, which can be replaced.  If this happens while
>> waiting for a write lock in either register or deregister, the code can end
>> up updating the counter on a pool that has been replaced.  I added checks
>> to trap deregistration of a null pool (should never happen) and followed
>> Sebb's suggestion to add a check for numInterested going negative.  The
>> accounting setup is very efficient, but tricky to maintain.  For 3.0, we
>> might consider moving numInterested tracking to a hashmap.  For 2.x, I
>> think the setup is fixed now and performance is the same as earlier
>> versions.  Soak tests look good.
>> 
>> One last thing I would like to do before we cut 2.12.0:
>> 
>> We are going to be making incompatible changes in 3.0 and I don't think we
>> need to telegraph all of the API changes via deprecations in 2.x - most
>> notably the recent method name changes of the form s/Time/Duration.  I
>> understand the rationale for these changes, but they make the 2.x code very
>> messy with double deprecations - first from the "millis" methods and then
>> from "Time" to "Duration."  I think it would be better to keep the existing
>> deprecations for the "millis" methods, but drop the new "Duration" ones and
>> remove deprecations for the ones they replace.  I can see the argument that
>> it is better to tell users now, but that takes away flexibility in 3.0 and
>> makes the API look very confusing with so many methods that do the same
>> thing.  Any objections ?
>> 
>> Phil
>> 
>>> On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz  wrote:
>>> 
>>> I have run my first round of soak and performance tests on what is now in
>>> the 2.x branch.  Good news is the code looks stable.  Not so good news is
>>> it appears that GKOP performance has taken a material hit vs 2.11 and
>>> earlier versions.  I need to confirm this via more targeted tests and if it
>>> turns out not to be real, figure out what is causing it.  Hopefully I will
>>> get to this done in the next few days.
>>> 
>>> Phil
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

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

Re: [pool] 2.12.0 update

[Phil Steitz]

OK, I found the source of the performance hit.  In the POOL-411 changes, we
had inadvertently forced every register to acquire a write lock from the
keylock.  I think I also finally definitively fixed the root issue there.
The tricky bit about the numInterested tracking is that the counters are
attached to the ObjectDeques, which can be replaced.  If this happens while
waiting for a write lock in either register or deregister, the code can end
up updating the counter on a pool that has been replaced.  I added checks
to trap deregistration of a null pool (should never happen) and followed
Sebb's suggestion to add a check for numInterested going negative.  The
accounting setup is very efficient, but tricky to maintain.  For 3.0, we
might consider moving numInterested tracking to a hashmap.  For 2.x, I
think the setup is fixed now and performance is the same as earlier
versions.  Soak tests look good.

One last thing I would like to do before we cut 2.12.0:

We are going to be making incompatible changes in 3.0 and I don't think we
need to telegraph all of the API changes via deprecations in 2.x - most
notably the recent method name changes of the form s/Time/Duration.  I
understand the rationale for these changes, but they make the 2.x code very
messy with double deprecations - first from the "millis" methods and then
from "Time" to "Duration."  I think it would be better to keep the existing
deprecations for the "millis" methods, but drop the new "Duration" ones and
remove deprecations for the ones they replace.  I can see the argument that
it is better to tell users now, but that takes away flexibility in 3.0 and
makes the API look very confusing with so many methods that do the same
thing.  Any objections ?

Phil

On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz  wrote:

> I have run my first round of soak and performance tests on what is now in
> the 2.x branch.  Good news is the code looks stable.  Not so good news is
> it appears that GKOP performance has taken a material hit vs 2.11 and
> earlier versions.  I need to confirm this via more targeted tests and if it
> turns out not to be real, figure out what is causing it.  Hopefully I will
> get to this done in the next few days.
>
> Phil
>

[pool] 2.12.0 update

[Phil Steitz]

I have run my first round of soak and performance tests on what is now in
the 2.x branch.  Good news is the code looks stable.  Not so good news is
it appears that GKOP performance has taken a material hit vs 2.11 and
earlier versions.  I need to confirm this via more targeted tests and if it
turns out not to be real, figure out what is causing it.  Hopefully I will
get to this done in the next few days.

Phil

Re: [pool] Another source compatibility break in 2.x

[Phil Steitz]

On Fri, Jul 21, 2023 at 5:17 AM Elliotte Rusty Harold 
wrote:

> On Thu, Jul 20, 2023 at 8:27 PM Phil Steitz  wrote:
> >
> > We have a minor source compat break still in 2.x
> >
> > The change to have BaseGenericObjectPool implement Autocloseable forced
> > addition of an abstract close method.  Technically, that could break
> > subclass implementations that don't implement close.  I see three options
> > here.  Maybe someone else has a better idea.
> >
> > 0) Ignore the problem.  Unlikely to actually impact anyone.
> > 1) Add a default implementation that
> > a) throws UnsupportedOperationException
> > b) No-Ops
> > c) does 
> > 2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...)
> instead
> > 3) Revert the change for 2.x
> >
>
> Weak vote for 1b. That maintains source compatibility and the API you
> want and doesn't seem likely to cause problems in any situation I can
> think of.
>

Thanks, Elliot.  The use case that I was worried about there was someone
assumes autoclosing for a pool that has not implemented close but uses some
other thing (like clear) to clean up resources and the no-op is
misleading.  I would rather get an exception in that case.  But it is kind
of far-fetched, so I am OK with the no-op default.

Phil

>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[pool] Another source compatibility break in 2.x

[Phil Steitz]

We have a minor source compat break still in 2.x

The change to have BaseGenericObjectPool implement Autocloseable forced
addition of an abstract close method.  Technically, that could break
subclass implementations that don't implement close.  I see three options
here.  Maybe someone else has a better idea.

0) Ignore the problem.  Unlikely to actually impact anyone.
1) Add a default implementation that
a) throws UnsupportedOperationException
b) No-Ops
c) does 
2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...) instead
3) Revert the change for 2.x

I am leaning toward 1a but I would also be OK with 0.  I don't much like 2
and I really don't like 3.  Option 2 could be remediated in pool 3, so the
ugliness would be temporary.   Any better ideas?

Phil

Re: [commons-pool] branch POOL_2_X updated: Add Duration named APIs and deprecate old APIs.

[Phil Steitz]

OK, I get it now.  I am just worried about making people change things
twice - first to a method that takes Duration rather than long and then to
another one that does the same thing but now has a different name.  How
about leaving the 2.x names as is, not adding new methods with the same
signatures but different names, keeping the old deprecated millis ones
marked deprecated and make the change to more easily disambiguate names in
3.x?  Otherwise, the 2.x code gets very cluttered and it also forces us to
finalize the 3.0 names now.  We made a bunch of name changes in 2.0 and I
think it is fair to do some of that in 3.0 as well.

On Thu, Jul 20, 2023 at 4:51 PM Gary Gregory  wrote:

> Hi Phil,
>
> There can get some ambiguity for me when I read code like (unless you know
> the API inside and out and use it on the daily):
>
> somePoolThing.getFooTime()
>
> Some of our methods return a Duration and others an Instant, so there, I
> think the type in the method name makes sense. Then, for a bit of symmetry,
> it's nice if the setter and getter names are the same (minus the set/get
> prefix obv).
>
> Gary
>
>
> On Tue, Jul 18, 2023, 17:38 Phil Steitz  wrote:
>
> > I like changing the arguments to be Duration, but that has already been
> > done.   What I am talking about is the method names, which is a second
> > change that I don't think is necessary.  For example, unless I am missing
> > something, before this commit, we had setTimeBetweenEvctionRuns(Duration)
> > and that is being deprecated and changed to
> > setDurationBetweenEvictionRuns(Duration).   I actually think the first
> name
> > is better.  It is natural English and it is not a good practice to put
> type
> > names in method names, IMO.  But more importantly, anyone who started
> using
> > this will have to change - in my mind needlessly.  Am I misreading the
> > diff?
> >
> > I would move to at least Java 11 for 3.0 and I would not keep JMX, but it
> > would be good to ask on the user list if anyone is depending on it /
> would
> > be seriously harmed if it goes away.  I think the Tomcat JMX may depend
> on
> > it, but I am not sure what the state of play there is vis a vis JMX.
> >
> > Phil
> >
> > On Tue, Jul 18, 2023 at 2:16 PM Gary Gregory 
> > wrote:
> >
> > > This will make it smoother to port to 3.0 where there will be no long
> > time
> > > APIs, the Duration type is used throughout (unless Instant is
> > appropriate).
> > > I have most of the deprecated methods removed locally and will push in
> a
> > > day or two.
> > >
> > > What remains:
> > > - do we want to keep the JMX code?
> > > - should 3.0 use Java 11 or 17?
> > >
> > > Gary
> > >
> > > On Tue, Jul 18, 2023, 16:41 Phil Steitz  wrote:
> > >
> > > > Why exactly do we need to s/Time/Duration in all of the method names?
> > > > Duration is a measure of time.  I don't get why this is necessary and
> > it
> > > > will force people to change (eventually).  I was +1 to get rid of the
> > > > "millis" in the names, but this change seems needless to me.  Also,
> > there
> > > > are still quite a few places where the text of the javadoc refers to
> > > > milliseconds.  Was this discussed before and I missed it?
> > > >
> > > > Phil
> > > >
> > > > On Tue, Jul 18, 2023 at 7:25 AM  wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > ggregory pushed a commit to branch POOL_2_X
> > > > > in repository https://gitbox.apache.org/repos/asf/commons-pool.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/POOL_2_X by this
> > push:
> > > > >  new 9d2f4af1 Add Duration named APIs and deprecate old APIs.
> > > > > 9d2f4af1 is described below
> > > > >
> > > > > commit 9d2f4af14dde121271c1bb862d4b1f236072eb2a
> > > > > Author: Gary Gregory 
> > > > > AuthorDate: Tue Jul 18 10:25:03 2023 -0400
> > > > >
> > > > > Add Duration named APIs and
> > > > > deprecate old APIs.
> > > > >
> > > > > Eases migration to 3.0.0
> > > > > ---
> > > > >  .../commons/pool2/impl/BaseGenericObjectPool.java  | 102
> > > > > +
> > > > >  .../commons/pool2/impl/BaseObjectPoolCo

Re: [Pool] Toward version 2.12.0 and 3.0

[Phil Steitz]

Exactly.  I think at major version cuts, we should drop support for JDKs
that are no longer supported [1].  Part of that is simply availability of
JDKs to test against and the implied commitment to do that testing and fix
bugs that may be JDK-specific.  Part of it is to allow use of new language
features.  We only have this opportunity once - when we start the new major
version - and IMO we should always take it.

Phil

[1] That is getting a little trickier now with LTS.

On Wed, Jul 19, 2023 at 2:42 PM Gary Gregory  wrote:

> The simplest way to bake in JPMS automatically is to build with the
> Moditect plugin and Java 11.
>
> There is also an expectation from new contributors that current development
> does not happen on the dead and EOL Java 8. It will be nice to at least
> have the option to use new language features and APIs.
>
> This is a major release and the perfect and expected time to bump Java
> versions IMO.
>
> Gary
>
>
> On Wed, Jul 19, 2023, 17:21 Alex Herbert  wrote:
>
> > On Wed, 19 Jul 2023 at 19:38, Gary Gregory 
> wrote:
> > >
> > > OK, that sounds good.
> > >
> > > Gary
> > >
> > > On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz 
> > wrote:
> > > >
> > > > I would say 17 for 3.0.
> > > >
> > > > Phil
> >
> > Are there aspects of Pool that require moving away from JDK 8? Such a
> > move would restrict downstream consumers of the library.
> >
> > Alex
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

[pool] advertising unchecked exceptions

[Phil Steitz]

I am going through now and comparing diffs of 2.11.1 and head of 2.x to
make sure that me and sed did not do anything wrong and I am seeing a bunch
of things like this:

-void addObject() throws Exception, IllegalStateException,
-UnsupportedOperationException;
+void addObject() throws Exception;

Where the new version is the 2.x code.  I am inclined to leave as is, maybe
adding comments in some places indicating when the unchecked exceptions
might be thrown.  Any objections?

Phil

Re: [Pool] Toward version 2.12.0 and 3.0

[Phil Steitz]

I would say 17 for 3.0.

Phil

On Mon, Jul 17, 2023 at 8:00 PM Gary Gregory  wrote:

> With 3.0, we should IMO bump to Java 11 or 17.
>
> FWIW, the only reason I have Java 8 on my machines are Apache projects like
> this one.
>
> Gary
>
> On Mon, Jul 17, 2023, 19:32 Gary Gregory  wrote:
>
> > Great, thanks for the update :-)
> >
> > Gary
> >
> > On Mon, Jul 17, 2023, 19:11 Phil Steitz  wrote:
> >
> >> +1
> >>
> >> I am doing soak tests now on the 2,x branch code and with DBCP.
> >>
> >> Phil
> >>
> >> On Sun, Jul 16, 2023 at 8:19 PM Gary Gregory 
> >> wrote:
> >>
> >> > The master branch is now on 3.0 and we have a 2.x branch as well.
> >> >
> >> > The next release will be 2.12.0 and then we can keep discussing how to
> >> > handle 3: exceptions and API changes.
> >> >
> >> > Gary
> >> >
> >> >
> >> > On Mon, Jul 3, 2023 at 2:01 PM Phil Steitz 
> >> wrote:
> >> > >
> >> > > +1
> >> > >
> >> > > Phil
> >> > >
> >> > > On Mon, Jul 3, 2023 at 9:41 AM Gary Gregory  >
> >> > wrote:
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > This is a switch from the 2.12.0 vote mail thread in order to
> >> discuss
> >> > 3.0
> >> > > > and 2.x releases.
> >> > > >
> >> > > > I propose we switch master to 3.0 and create a branch called 2.x
> >> based
> >> > and
> >> > > > an old commit and release 2.12.0 from there.
> >> > > >
> >> > > > Gary
> >> > > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >>
> >
>

Re: [Pool] Toward version 2.12.0 and 3.0

[Phil Steitz]

I think we probably should keep it.  I see now tomcat still supports it, so
would require more forking / munging to add it back if we drop it.  There
may be other downstreams that depend on it.  So I would say keep it.

On Mon, Jul 17, 2023 at 7:59 PM Gary Gregory  wrote:

> Do we want to keep JMX support for 3.0?
>
> Just curious,
> Gary
>
> On Mon, Jul 17, 2023, 19:32 Gary Gregory  wrote:
>
> > Great, thanks for the update :-)
> >
> > Gary
> >
> > On Mon, Jul 17, 2023, 19:11 Phil Steitz  wrote:
> >
> >> +1
> >>
> >> I am doing soak tests now on the 2,x branch code and with DBCP.
> >>
> >> Phil
> >>
> >> On Sun, Jul 16, 2023 at 8:19 PM Gary Gregory 
> >> wrote:
> >>
> >> > The master branch is now on 3.0 and we have a 2.x branch as well.
> >> >
> >> > The next release will be 2.12.0 and then we can keep discussing how to
> >> > handle 3: exceptions and API changes.
> >> >
> >> > Gary
> >> >
> >> >
> >> > On Mon, Jul 3, 2023 at 2:01 PM Phil Steitz 
> >> wrote:
> >> > >
> >> > > +1
> >> > >
> >> > > Phil
> >> > >
> >> > > On Mon, Jul 3, 2023 at 9:41 AM Gary Gregory  >
> >> > wrote:
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > This is a switch from the 2.12.0 vote mail thread in order to
> >> discuss
> >> > 3.0
> >> > > > and 2.x releases.
> >> > > >
> >> > > > I propose we switch master to 3.0 and create a branch called 2.x
> >> based
> >> > and
> >> > > > an old commit and release 2.12.0 from there.
> >> > > >
> >> > > > Gary
> >> > > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >>
> >
>

Re: [commons-pool] branch POOL_2_X updated: Add Duration named APIs and deprecate old APIs.

[Phil Steitz]

I like changing the arguments to be Duration, but that has already been
done.   What I am talking about is the method names, which is a second
change that I don't think is necessary.  For example, unless I am missing
something, before this commit, we had setTimeBetweenEvctionRuns(Duration)
and that is being deprecated and changed to
setDurationBetweenEvictionRuns(Duration).   I actually think the first name
is better.  It is natural English and it is not a good practice to put type
names in method names, IMO.  But more importantly, anyone who started using
this will have to change - in my mind needlessly.  Am I misreading the diff?

I would move to at least Java 11 for 3.0 and I would not keep JMX, but it
would be good to ask on the user list if anyone is depending on it / would
be seriously harmed if it goes away.  I think the Tomcat JMX may depend on
it, but I am not sure what the state of play there is vis a vis JMX.

Phil

On Tue, Jul 18, 2023 at 2:16 PM Gary Gregory  wrote:

> This will make it smoother to port to 3.0 where there will be no long time
> APIs, the Duration type is used throughout (unless Instant is appropriate).
> I have most of the deprecated methods removed locally and will push in a
> day or two.
>
> What remains:
> - do we want to keep the JMX code?
> - should 3.0 use Java 11 or 17?
>
> Gary
>
> On Tue, Jul 18, 2023, 16:41 Phil Steitz  wrote:
>
> > Why exactly do we need to s/Time/Duration in all of the method names?
> > Duration is a measure of time.  I don't get why this is necessary and it
> > will force people to change (eventually).  I was +1 to get rid of the
> > "millis" in the names, but this change seems needless to me.  Also, there
> > are still quite a few places where the text of the javadoc refers to
> > milliseconds.  Was this discussed before and I missed it?
> >
> > Phil
> >
> > On Tue, Jul 18, 2023 at 7:25 AM  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > ggregory pushed a commit to branch POOL_2_X
> > > in repository https://gitbox.apache.org/repos/asf/commons-pool.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/POOL_2_X by this push:
> > >  new 9d2f4af1 Add Duration named APIs and deprecate old APIs.
> > > 9d2f4af1 is described below
> > >
> > > commit 9d2f4af14dde121271c1bb862d4b1f236072eb2a
> > > Author: Gary Gregory 
> > > AuthorDate: Tue Jul 18 10:25:03 2023 -0400
> > >
> > > Add Duration named APIs and
> > > deprecate old APIs.
> > >
> > > Eases migration to 3.0.0
> > > ---
> > >  .../commons/pool2/impl/BaseGenericObjectPool.java  | 102
> > > +
> > >  .../commons/pool2/impl/BaseObjectPoolConfig.java   |  32 ++-
> > >  .../commons/pool2/impl/GenericKeyedObjectPool.java |   2 +-
> > >  .../commons/pool2/impl/GenericObjectPool.java  |   2 +-
> > >  .../apache/commons/pool2/ObjectPoolIssue326.java   |   2 +
> > >  .../java/org/apache/commons/pool2/PoolTest.java|   2 +-
> > >  .../pool2/impl/TestAbandonedKeyedObjectPool.java   |   2 +-
> > >  .../pool2/impl/TestAbandonedObjectPool.java|   2 +-
> > >  .../pool2/impl/TestGenericKeyedObjectPool.java |   5 +-
> > >  .../commons/pool2/impl/TestGenericObjectPool.java  |   6 +-
> > >  .../impl/TestGenericObjectPoolClassLoaders.java|   4 +-
> > >  .../TestGenericObjectPoolFactoryCreateFailure.java |   3 +-
> > >  12 files changed, 131 insertions(+), 33 deletions(-)
> > >
> > > diff --git
> > >
> a/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> > >
> b/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> > > index 4277ce86..fc95ba32 100644
> > > ---
> > >
> a/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> > > +++
> > >
> b/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> > > @@ -867,7 +867,7 @@ public abstract class BaseGenericObjectPool
> > extends
> > > BaseObject implements Aut
> > >  /**
> > >   * Gets the minimum amount of time an object may sit idle in the
> > pool
> > >   * before it is eligible for eviction by the idle object evictor
> (if
> > > any -
> > > - * see {@link #setTimeBetweenEvictionRuns(Duration)}). When
> > > non-positive,
> > > + * see {@link #setDurationBetweenEvictionRuns(Duration)}). When
> > > non-positive,
> > >   * no

Re: [commons-pool] branch POOL_2_X updated: Add Duration named APIs and deprecate old APIs.

[Phil Steitz]

Why exactly do we need to s/Time/Duration in all of the method names?
Duration is a measure of time.  I don't get why this is necessary and it
will force people to change (eventually).  I was +1 to get rid of the
"millis" in the names, but this change seems needless to me.  Also, there
are still quite a few places where the text of the javadoc refers to
milliseconds.  Was this discussed before and I missed it?

Phil

On Tue, Jul 18, 2023 at 7:25 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch POOL_2_X
> in repository https://gitbox.apache.org/repos/asf/commons-pool.git
>
>
> The following commit(s) were added to refs/heads/POOL_2_X by this push:
>  new 9d2f4af1 Add Duration named APIs and deprecate old APIs.
> 9d2f4af1 is described below
>
> commit 9d2f4af14dde121271c1bb862d4b1f236072eb2a
> Author: Gary Gregory 
> AuthorDate: Tue Jul 18 10:25:03 2023 -0400
>
> Add Duration named APIs and
> deprecate old APIs.
>
> Eases migration to 3.0.0
> ---
>  .../commons/pool2/impl/BaseGenericObjectPool.java  | 102
> +
>  .../commons/pool2/impl/BaseObjectPoolConfig.java   |  32 ++-
>  .../commons/pool2/impl/GenericKeyedObjectPool.java |   2 +-
>  .../commons/pool2/impl/GenericObjectPool.java  |   2 +-
>  .../apache/commons/pool2/ObjectPoolIssue326.java   |   2 +
>  .../java/org/apache/commons/pool2/PoolTest.java|   2 +-
>  .../pool2/impl/TestAbandonedKeyedObjectPool.java   |   2 +-
>  .../pool2/impl/TestAbandonedObjectPool.java|   2 +-
>  .../pool2/impl/TestGenericKeyedObjectPool.java |   5 +-
>  .../commons/pool2/impl/TestGenericObjectPool.java  |   6 +-
>  .../impl/TestGenericObjectPoolClassLoaders.java|   4 +-
>  .../TestGenericObjectPoolFactoryCreateFailure.java |   3 +-
>  12 files changed, 131 insertions(+), 33 deletions(-)
>
> diff --git
> a/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> b/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> index 4277ce86..fc95ba32 100644
> ---
> a/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> +++
> b/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
> @@ -867,7 +867,7 @@ public abstract class BaseGenericObjectPool extends
> BaseObject implements Aut
>  /**
>   * Gets the minimum amount of time an object may sit idle in the pool
>   * before it is eligible for eviction by the idle object evictor (if
> any -
> - * see {@link #setTimeBetweenEvictionRuns(Duration)}). When
> non-positive,
> + * see {@link #setDurationBetweenEvictionRuns(Duration)}). When
> non-positive,
>   * no objects will be evicted from the pool due to idle time alone.
>   *
>   * @return minimum amount of time an object may sit idle in the pool
> before
> @@ -884,7 +884,7 @@ public abstract class BaseGenericObjectPool extends
> BaseObject implements Aut
>  /**
>   * Gets the minimum amount of time an object may sit idle in the pool
>   * before it is eligible for eviction by the idle object evictor (if
> any -
> - * see {@link #setTimeBetweenEvictionRuns(Duration)}). When
> non-positive,
> + * see {@link #setDurationBetweenEvictionRuns(Duration)}). When
> non-positive,
>   * no objects will be evicted from the pool due to idle time alone.
>   *
>   * @return minimum amount of time an object may sit idle in the pool
> before
> @@ -1017,7 +1017,7 @@ public abstract class BaseGenericObjectPool
> extends BaseObject implements Aut
>  /**
>   * Gets the minimum amount of time an object may sit idle in the pool
>   * before it is eligible for eviction by the idle object evictor (if
> any -
> - * see {@link #setTimeBetweenEvictionRuns(Duration)}),
> + * see {@link #setDurationBetweenEvictionRuns(Duration)}),
>   * with the extra condition that at least {@code minIdle} object
>   * instances remain in the pool. This setting is overridden by
>   * {@link #getMinEvictableIdleTime} (that is, if
> @@ -1027,7 +1027,7 @@ public abstract class BaseGenericObjectPool
> extends BaseObject implements Aut
>   * @return minimum amount of time an object may sit idle in the pool
> before
>   * it is eligible for eviction if minIdle instances are
> available
>   *
> - * @see #setSoftMinEvictableIdle(Duration)
> + * @see #setSoftMinEvictableIdleDuration(Duration)
>   * @since 2.11.0
>   */
>  public final Duration getSoftMinEvictableIdleDuration() {
> @@ -1037,7 +1037,7 @@ public abstract class BaseGenericObjectPool
> extends BaseObject implements Aut
>  /**
>   * Gets the minimum amount of time an object may sit idle in the pool
>   * before it is eligible for eviction by the idle object evictor (if
> any -
> - * see {@link #setTimeBetweenEvictionRuns(Duration)}),
> + * see {@link #setDurationBetweenEvictionRuns(Duration)}),
>   * with the extra condi

Re: [Pool] Toward version 2.12.0 and 3.0

[Phil Steitz]

+1

I am doing soak tests now on the 2,x branch code and with DBCP.

Phil

On Sun, Jul 16, 2023 at 8:19 PM Gary Gregory  wrote:

> The master branch is now on 3.0 and we have a 2.x branch as well.
>
> The next release will be 2.12.0 and then we can keep discussing how to
> handle 3: exceptions and API changes.
>
> Gary
>
>
> On Mon, Jul 3, 2023 at 2:01 PM Phil Steitz  wrote:
> >
> > +1
> >
> > Phil
> >
> > On Mon, Jul 3, 2023 at 9:41 AM Gary Gregory 
> wrote:
> >
> > > Hi all,
> > >
> > > This is a switch from the 2.12.0 vote mail thread in order to discuss
> 3.0
> > > and 2.x releases.
> > >
> > > I propose we switch master to 3.0 and create a branch called 2.x based
> and
> > > an old commit and release 2.12.0 from there.
> > >
> > > Gary
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [pool] Creating the 2.x branch

[Phil Steitz]

> On Jul 12, 2023, at 7:14 PM, Gary Gregory  wrote:
> 
> My initial impression is that creating a script that edits sources
> correctly will take longer to write than editing the head of master to
> remove some of the generics. Recall that the code has other generics.
> 
> I am guessing that a manual edit is probably a half day to a full day of
> work, I'm not sure how much editing the tests would need.
> 
> My gut feel is that it is safer to take the head of master, create a 2.x.y
> branch and edit that, and switch master to 3.0.0. This pretty much
> guarantees that neither branch will miss any fix.

Thanks, Gary.  I will take that approach.  

Phil
> 
> Gary
> 
> 
>> On Wed, Jul 12, 2023, 14:29 Phil Steitz  wrote:
>> 
>> I think the code in master is close to releasable modulo the breaking
>> change that we have agreed should move to 3.x.  The clean way to proceed on
>> the 2.x branch would be to go back to the commit that introduced the new
>> exception type parameter, cut the branch from there and then port all of
>> the subsequent changes.  That would be a lot of manual work to do
>> individually, referencing each commit.  Do we think that this is necessary?
>> 
>> I see two alternatives.  One is to cut the 2.x branch from master and write
>> a script to make the changes to remove the type parameters, then do one
>> commit to revert that change.  Second is to do basically the same thing,
>> only creating the branch from the prior commit, then one big commit to both
>> port subsequent changes and get rid of the type parameters.
>> 
>> I am OK if people think we need to go back to the breaking commit and
>> individually port commits from there.  It will just take a little longer.
>> I am also obviously open to any better suggestions on how to do this.
>> 
>> Phil
>> 

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

[pool] Creating the 2.x branch

[Phil Steitz]

I think the code in master is close to releasable modulo the breaking
change that we have agreed should move to 3.x.  The clean way to proceed on
the 2.x branch would be to go back to the commit that introduced the new
exception type parameter, cut the branch from there and then port all of
the subsequent changes.  That would be a lot of manual work to do
individually, referencing each commit.  Do we think that this is necessary?

I see two alternatives.  One is to cut the 2.x branch from master and write
a script to make the changes to remove the type parameters, then do one
commit to revert that change.  Second is to do basically the same thing,
only creating the branch from the prior commit, then one big commit to both
port subsequent changes and get rid of the type parameters.

I am OK if people think we need to go back to the breaking commit and
individually port commits from there.  It will just take a little longer.
I am also obviously open to any better suggestions on how to do this.

Phil

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

I think I may have figured this out.  I reopened and added a comment to
POOL-411.

Phil

On Thu, Jul 6, 2023 at 2:41 PM Phil Steitz  wrote:

> 
>
> I guess it's good news that CI hit the error below when reviewing the PR
> that I had prepared for the POOL-391 fixes.  I only saw it once in many
> test runs and only on OpenJDK 20.0.1.  Looks like CI is running 17 on
> azure-linux.  I am pretty sure it has nothing to do with the changes in the
> PR, partly because I saw it once running the first RC code.
>
> This is very strange and troubling.  More eyeballs most welcome.  Here is
> the problem:
>
> The NPE below happens inside GKOP addIdleObject, which is called by
> addObject.  The code for addObject follows the standard pattern:
> register(key);
> try {
> addIdleObject(key, create(key));
> } finally {
> deregister(key);
> }
>
> So addIdleObject is called while the owning thread has the key
> "registered."  To register is key is basically sayinig you are interested
> in / about to do something to its associated pool.  There is a
> numInterested counter (attached to the keyed pool) that gets incremented
> when a thread registers a key and decrremented when the key is
> deregistered. Registration creates a pool and iniitializes its counter if
> there is no pool under the given key.   When pools are deregistered, the
> counter is checked and if the pool has no instances under management and
> the counter is zero, the pool is removed.  In this case, the registration
> in addObject should prevent the pool being removed before or during
> execution of addIdleObject, but the NPE means it has been removed.  Somehow
> numInterested is getting corrupted.
>
> I will keep trying to get this to happen and see if I can find scenarios
> where deregister is somehow called twice for one register.  Any suggestions
> or success getting this to happen with the code now in master most
> appreciated.
>
> Phil
>
>> 2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure just 
>> one time and can't reproduce:
>>
>> java.util.concurrent.ExecutionException: java.lang.NullPointerException: 
>> Cannot invoke 
>> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
>>  because the return value of "java.util.Map.get(Object)" is null
>>
>>  at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>>  at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>>  at 
>> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$2(TestGenericKeyedObjectPool.java:1056)
>>  ... 71 more
>> Caused by: java.lang.NullPointerException: Cannot invoke 
>> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
>>  because the return value of "java.util.Map.get(Object)" is null
>>  at 
>> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addIdleObject(GenericKeyedObjectPool.java:307)
>>  at 
>> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addObject(GenericKeyedObjectPool.java:332)
>>  at 
>> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:136)
>>  at 
>> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:113)
>>  at 
>> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$0(TestGenericKeyedObjectPool.java:1036)
>>  at 
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
>>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
>>  at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
>>  at 
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
>>  at java.base/java.lang.Thread.run(Thread.java:1623)
>>
>>
>>
>>

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

I guess it's good news that CI hit the error below when reviewing the PR
that I had prepared for the POOL-391 fixes.  I only saw it once in many
test runs and only on OpenJDK 20.0.1.  Looks like CI is running 17 on
azure-linux.  I am pretty sure it has nothing to do with the changes in the
PR, partly because I saw it once running the first RC code.

This is very strange and troubling.  More eyeballs most welcome.  Here is
the problem:

The NPE below happens inside GKOP addIdleObject, which is called by
addObject.  The code for addObject follows the standard pattern:
register(key);
try {
addIdleObject(key, create(key));
} finally {
deregister(key);
}

So addIdleObject is called while the owning thread has the key
"registered."  To register is key is basically sayinig you are interested
in / about to do something to its associated pool.  There is a
numInterested counter (attached to the keyed pool) that gets incremented
when a thread registers a key and decrremented when the key is
deregistered. Registration creates a pool and iniitializes its counter if
there is no pool under the given key.   When pools are deregistered, the
counter is checked and if the pool has no instances under management and
the counter is zero, the pool is removed.  In this case, the registration
in addObject should prevent the pool being removed before or during
execution of addIdleObject, but the NPE means it has been removed.  Somehow
numInterested is getting corrupted.

I will keep trying to get this to happen and see if I can find scenarios
where deregister is somehow called twice for one register.  Any suggestions
or success getting this to happen with the code now in master most
appreciated.

Phil

> 2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure just one 
> time and can't reproduce:
>
> java.util.concurrent.ExecutionException: java.lang.NullPointerException: 
> Cannot invoke 
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
>  because the return value of "java.util.Map.get(Object)" is null
>
>   at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>   at 
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$2(TestGenericKeyedObjectPool.java:1056)
>   ... 71 more
> Caused by: java.lang.NullPointerException: Cannot invoke 
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
>  because the return value of "java.util.Map.get(Object)" is null
>   at 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addIdleObject(GenericKeyedObjectPool.java:307)
>   at 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addObject(GenericKeyedObjectPool.java:332)
>   at 
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:136)
>   at 
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:113)
>   at 
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$0(TestGenericKeyedObjectPool.java:1036)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
>   at java.base/java.lang.Thread.run(Thread.java:1623)
>
>
>
>

Re: [Pool] Toward version 2.12.0 and 3.0

[Phil Steitz]

+1

Phil

On Mon, Jul 3, 2023 at 9:41 AM Gary Gregory  wrote:

> Hi all,
>
> This is a switch from the 2.12.0 vote mail thread in order to discuss 3.0
> and 2.x releases.
>
> I propose we switch master to 3.0 and create a branch called 2.x based and
> an old commit and release 2.12.0 from there.
>
> Gary
>

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

On Mon, Jul 3, 2023 at 6:41 AM Gary Gregory  wrote:

> On Thu, Jun 29, 2023 at 5:08 PM Phil Steitz  wrote:
> >
> > On Thu, Jun 29, 2023 at 11:39 AM Gary Gregory 
> > wrote:
> >
> > > Great presentation in the video Elliotte. Thanks for sharing the link.
> > >
> >
> > +1 many thanks.
> >
> > Now back to our hero.  Let me pretend to be one of the people in the
> > audience of the video.
> >
> > We have this library that is used by all kinds of "programs" [1] and we
> are
> > not sure how best to a) type our own exceptions (the ones we generate)
> and
> > b) propagate the ones generated by user-supplied object factories.
> Broadly
> > speaking, we have four kinds of exceptions to deal with:
> >
> > 0) User-supplied object factories that the pool uses to perform pooled
> > object lifecycle operations may throw checked or unchecked exceptions.
> > Many of these will be the classic variety you mention in the video -
> > database is dead, etc when the factory is trying to open a physical
> > connection.  The smelly "throws Exception" in place now lets us just pass
> > these all up the stack, but essentially untyped.
> > 1) Pool clients want to do something, but the pool can't do it without
> > violating one of its invariants (most common is a client wants to borrow
> an
> > object and, after waiting the configured interval, there is no capacity
> to
> > serve).  We are inconsistent here.  In the out of capacity case, we throw
> > NoSuchElementException (probably bogus according to your taxonomy), but
> in
> > some cases - e.g. addObject - we silently no-op.
> > 2) An API is abused (e.g. return an object that did not come from the
> pool
> > or try to start borrowing objects before providing a factory)
> > 3) Something happens that should not be possible (indicating some kind of
> > concurrency bug in [pool] itself or unanticipated craziness from a
> factory
> > or client code)
> >
> > There is a lot of complexity in the 0)-1) cases because some failures are
> > more important to both the pool and clients than others (for example,
> > factory exceptions thrown in object validation or destruction are
> different
> > from those thrown in object creation).
> >
> > If I understand your advice, it would be:
> > 0) checked if that is what comes from the factory; just propagate
> otherwise
> > 1) checked?  Maybe actually no exception - handle via return values or
> > somesuch?  By far the most common here is NoSuchElementException.  I
> guess
> > it's OK to see pool exhaustion as "environmental" [2], so probably
> checked
> > is actually right
> > 2) unchecked
> > 3) unchecked
> >
> > Assuming I got 0) right at least, the follow-up is how do we get the
> right
> > exceptions passed up the stack?  What Gary is proposing is adding a type
> > parameter at the pool level.  Could be that is the best solution, but
> that
> > adds to complexity of the API and I keep wanting it to be defined at the
> > factory level somehow and ideally have it default to something so users
> who
> > don't want to think about it (maybe because their factories only throw
> > unchecked exceptions) don't have to think about it.
> >
> > I would be remiss not to add a closing (at this point probably annoying)
> > comment to the effect that this should be a 3.0 discussion :)
>
> I am OK with all of this being for 3.0, which can be as soon as we want.
>

Thanks, Gary.  We should probably end this thread then and start a new one
on 3.0 planning.  As a side note, I discovered that the failures reported
to the console but not causing test failure that I saw were real, due to
problems in GKOP reuseCapacity.  The OP test case for POOL-391 is
demanding, but we should be able to handle it. It was not causing the test
to fail because the runner does not see failures in spawned threads.  My
bad not knowing that.  Once I set it up so the failures would fail the
test, they did consistently.  I have been working on and off on this over
the last week and I think I am close to a fix.  Once I have this, I think
it would be good to roll a 2.12 without the compat break because there are
quite a few bug fixes in the RC.  Would you be OK either rolling back the
added type parameter change or moving it to a new 3.0 branch?  Or I guess
alternatively, creating a 2.x branch without that change?   I can help with
either of these.

Phil

>
> Gary
>
> >
> > Phil
> >
> > [1] It is hard for us to understand what is and is not in "our program"
> as
> > library developers

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

On Thu, Jun 29, 2023 at 11:39 AM Gary Gregory 
wrote:

> Great presentation in the video Elliotte. Thanks for sharing the link.
>

+1 many thanks.

Now back to our hero.  Let me pretend to be one of the people in the
audience of the video.

We have this library that is used by all kinds of "programs" [1] and we are
not sure how best to a) type our own exceptions (the ones we generate) and
b) propagate the ones generated by user-supplied object factories.  Broadly
speaking, we have four kinds of exceptions to deal with:

0) User-supplied object factories that the pool uses to perform pooled
object lifecycle operations may throw checked or unchecked exceptions.
Many of these will be the classic variety you mention in the video -
database is dead, etc when the factory is trying to open a physical
connection.  The smelly "throws Exception" in place now lets us just pass
these all up the stack, but essentially untyped.
1) Pool clients want to do something, but the pool can't do it without
violating one of its invariants (most common is a client wants to borrow an
object and, after waiting the configured interval, there is no capacity to
serve).  We are inconsistent here.  In the out of capacity case, we throw
NoSuchElementException (probably bogus according to your taxonomy), but in
some cases - e.g. addObject - we silently no-op.
2) An API is abused (e.g. return an object that did not come from the pool
or try to start borrowing objects before providing a factory)
3) Something happens that should not be possible (indicating some kind of
concurrency bug in [pool] itself or unanticipated craziness from a factory
or client code)

There is a lot of complexity in the 0)-1) cases because some failures are
more important to both the pool and clients than others (for example,
factory exceptions thrown in object validation or destruction are different
from those thrown in object creation).

If I understand your advice, it would be:
0) checked if that is what comes from the factory; just propagate otherwise
1) checked?  Maybe actually no exception - handle via return values or
somesuch?  By far the most common here is NoSuchElementException.  I guess
it's OK to see pool exhaustion as "environmental" [2], so probably checked
is actually right
2) unchecked
3) unchecked

Assuming I got 0) right at least, the follow-up is how do we get the right
exceptions passed up the stack?  What Gary is proposing is adding a type
parameter at the pool level.  Could be that is the best solution, but that
adds to complexity of the API and I keep wanting it to be defined at the
factory level somehow and ideally have it default to something so users who
don't want to think about it (maybe because their factories only throw
unchecked exceptions) don't have to think about it.

I would be remiss not to add a closing (at this point probably annoying)
comment to the effect that this should be a 3.0 discussion :)

Phil

[1] It is hard for us to understand what is and is not in "our program" as
library developers.  Our code is always running inside someone else's
program, often using yet another third party's code.  So for example, in a
common use case, [pool] is used by [dbcp] which is used by tomcat, with
factories specified in a user webapp running in tomcat, wrapped into [dbcp]
and managed by [pool].
[2] Though many/most actual cases of this in production code end up being
the result of self-DOS due to programming errors.

>
> Gary
>
> On Thu, Jun 29, 2023, 10:33 Elliotte Rusty Harold 
> wrote:
>
> > On Thu, Jun 29, 2023 at 10:10 AM Gilles Sadowski 
> > wrote:
> > >
> > > Le jeu. 29 juin 2023 à 15:22, Elliotte Rusty Harold
> > >  a écrit :
> > > >
> > > > On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski <
> gillese...@gmail.com>
> > wrote:
> > > > >
> > > > > Hello.
> > > > >
> > > > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory  >
> > a écrit :
> > > >
> > > > > I agree with the second part assuming the *current* Java
> > > > > best practices, not because of old APIs that are here to stay
> > > > > only because of infinite backwards compatibility, and not
> > > > > because they are deemed perfect.
> > > >
> > > >
> > > > Best practices on this haven't changed since Java 1.0 (Possibly Java
> > > > 1.0 alpha 3 if I recall versions correctly).
> > > >
> > > > Checked exceptions: all errors arising from external input to the
> > program.
> > > > Runtime exceptions: program bugs
> > >
> > > A pile of arguments (tally is largely against *any* use of checked
> > exceptions):
> > >
> >
> https://ohadshai.medium.com/its-almost-2020-and-yet-checked-exceptions-are-still-a-thing-bfaa24c8997e
> >
> > tldr; he's wrong. More details:
> > https://www.youtube.com/watch?v=rJ-Ihh7RNao&t=419s
> >
> > > >
> > > > I don't know which applies here, but 99% of the time this is all you
> > > > need to consider to figure out whether a checked or runtime exception
> > > > is called for. There are indeed a lot of old broken APIs that don't
> > > > follow these simple rules

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

hrough a _second_ round of
> compiling and running your sources. IOW, (TTD or not) you write a
> combination of test and main code, run it, and start iterating tests
> and main code, and now you have to deal with _unexpected_ unchecked
> exceptions, unless you've read the Javadoc and/or sources for all the
> APIs you're calling, and then wrote _correct_ code. With checked
> exceptions, you're forced to make that exception handing decision
> upfront or your code won't compile. It's a different experience for
> users of the API. I'm not judging it either way, it's just different.
>

I agree with this.

>
> Question: What's the experience we want to give Pool users, the people
> who write calls to the API?
>

Make it as easy as possible to safely use the component.  More generic type
parameters == more cognitive load which to me means makes it harder to
use.  But I can anticipate the response to this - crazy "throws Exception"
makes me have to shoehorn my domain exception hierarchy in somehow == more
cognitive load.  I am not sure which is right, but I know that every time I
go to use a library, I want to spend as little time as possible
understanding its way of looking at things.  Overall, the pool API is not
bad at that, but we may be able to make it easier in some ways and I am
big +1 for that.  The other big thing I keep hammering on is that as a user
I absolutely don't want to be surprised by build breaks in minor releases.
Major releases, I know I may have to tweak some things / think a bit about
the new way the component thinks about the world.  And I can decide if I
want to go there.  Minor release, to get bug fixes I just want to drop it
in, build, and have it work.

>
> I'm not sold 100% on either approach. I consider Pool a mid-level API,
> as opposed to a low-level API. Calling a low-level API, I am OK
> handling/propagating checked exceptions. I see Pool as a
> semi-transparent proxy to the actual API/Objects being pooled, so I am
> OK with checked exceptions coming out of Pool just like I am OK with
> checked exceptions coming from a file or database API. My point here
> is that changing to unchecked API feels to me like raising the
> abstraction level of the API. It would mean that we pool and transform
> exceptions from checked to unchecked (or, leave them unchecked, or
> wrap unchecked domain APIs with Pool unchecked APIs).
>
> What do people think? Is the future checked or unchecked? As is Java
> taking on developer-friendly features ("var" for example, and
> unfriendly, hello JPMS), are checked exceptions just getting in the
> way? Are checked exceptions a step too far in a statically typed
> language?
>
> I did not get the points Phil is trying to make in his examples, I'm
> not sure they are valid. OTOH, the unit tests do show using the APIs
> typed with different types of exceptions. Sure, there might be
> adjustments to make, but I don't see the flaws you seem to think are
> there. WRT to source changes, I welcome cleaning up my call sites!


 The problem is you are asking *many* users to be welcoming of this task,
which I do not think should happen in a minor release.

The
> debate is valid and I hope we have interesting replies to this thread.
>
> Thank you for reading all of this!
>

Thank you for explaining, Gary.

Phil

> Gary
>
> On Mon, Jun 26, 2023 at 7:44 PM Phil Steitz  wrote:
> >
> > Looking more carefully at the extent of impact, I am -1 (non-binding) on
> > this change.  I understand what you are trying to do, but a) I don't see
> > that the solution actually does it (see comments by Michael in PR) and b)
> > it is going to create a lot of pain for users who have to modify
> factories,
> > etc. when in fact many / most of them throw unchecked if any
> exceptions.  I
> > would be +1 for removing the throws entirely in 3.0.  It does not make
> > sense to me to have a "generic" checked exception type assigned at the
> pool
> > level.  What the different factory and pool methods throw may be
> > different.  Even after your change, for example,  borrowObject throws
> NSE.
> > You are changing the signature to make it look like if you catch "E"
> > whatever that is, it will not go bang.  But it will if you have replaced
> > "Exception" with a checked exception class. You are just replacing
> > "Exception" with something that looks "cleaner" but is not.  Clients will
> > either have to ignore it and just instantiate with "Exception" or create
> a
> > gratuitous "FooException" to root a hierarchy of their own making (and
> > separately catch the NSEs) when in fact what the

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

Looking more carefully at the extent of impact, I am -1 (non-binding) on
this change.  I understand what you are trying to do, but a) I don't see
that the solution actually does it (see comments by Michael in PR) and b)
it is going to create a lot of pain for users who have to modify factories,
etc. when in fact many / most of them throw unchecked if any exceptions.  I
would be +1 for removing the throws entirely in 3.0.  It does not make
sense to me to have a "generic" checked exception type assigned at the pool
level.  What the different factory and pool methods throw may be
different.  Even after your change, for example,  borrowObject throws NSE.
You are changing the signature to make it look like if you catch "E"
whatever that is, it will not go bang.  But it will if you have replaced
"Exception" with a checked exception class. You are just replacing
"Exception" with something that looks "cleaner" but is not.  Clients will
either have to ignore it and just instantiate with "Exception" or create a
gratuitous "FooException" to root a hierarchy of their own making (and
separately catch the NSEs) when in fact what they throw now are standard
exceptions.  Remember pool is very widely used so you are asking  *many*
developers to spend time making changes that many will consider a waste of
time. Is the idea that they all just parameterize with "Exception"?  Can
IDEs do that automatically for them?  Please let's get some input from
downstream users before surprising them with this.

Phil

On Mon, Jun 26, 2023 at 3:55 PM Phil Steitz  wrote:

>
>
> On Mon, Jun 26, 2023 at 3:43 PM Gary Gregory 
> wrote:
>
>> Hi Phil,
>>
>> YW and thank you for the review.
>>
>> Yes, you are right that this is about POOL-269. While binary compatibility
>> is preserved 100%, source compatibility is not. This is one of those rare
>> cases where you can't make an omelette without breaking some eggs ;-)
>> Since
>> binary compatibility is preserved, I don't think this is worth going to a
>> new major release.
>>
>
> We should definitely add a *loud* statement in the release notes then and
> directions for how to work around because I am sure a lot of downstream
> builds will fail due to this as DBCP did.  Is there no way that we can
> somehow keep the source compatability?  Pool is widely used and a lot of
> builds will break IIUC what is going on here.
>
> Phil
>
>>
>> I have POOL projects that will benefit (greatly IMO) from cleaner
>> exception
>> handling and avoid having to throw/propagate Exception or catch/rethrow
>> Exception as a domain Exception, and will now instead be able to use
>> domain
>> specific exception for resources being pooled from the get go.
>>
>> I'll obviously adjust DBCP for this as soon as possible (IOW,
>> post-release).
>>
>> For the other items, I will try and reproduce. My tests builds were ok on
>> Windows 10 and macOS latest with Java 8. Maybe by hardware is too slow or
>> too fast compared to yours, hard to say.
>>
>> Gary
>>
>> On Mon, Jun 26, 2023, 16:53 Phil Steitz  wrote:
>>
>> > Hi Gary, First, thanks for doing this.  There are a lot of good fixes in
>> > here.
>> >
>> > I checked the build, sigs et al on a couple of platforms and did not
>> > find anything major except one item.  I will start with the
>> > show-stopper (IMO) and then the other smaller things.
>> >
>> > 1.  I get compilation failure when I try to compile the latest DBCP
>> > release with this code.  I think it may have something to do with
>> > POOL-269.  Here is one example:
>> >
>> > [*ERROR*]
>> >
>> /Users/psteitz/Downloads/commons-dbcp2-2.9.0-src/src/main/java/org/apache/commons/dbcp2/PoolableConnectionFactory.java:[45,70]
>> > wrong number of type arguments; required 2
>> >
>> > This should not happen in a dot release.
>> >
>> > 2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure
>> > just one time and can't reproduce:
>> >
>> > java.util.concurrent.ExecutionException:
>> > java.lang.NullPointerException: Cannot invoke
>> >
>> >
>> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
>> > because the return value of "java.util.Map.get(Object)" is null
>> >
>> > at
>> > java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>> > at
>> > java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>> > 

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

On Mon, Jun 26, 2023 at 3:43 PM Gary Gregory  wrote:

> Hi Phil,
>
> YW and thank you for the review.
>
> Yes, you are right that this is about POOL-269. While binary compatibility
> is preserved 100%, source compatibility is not. This is one of those rare
> cases where you can't make an omelette without breaking some eggs ;-) Since
> binary compatibility is preserved, I don't think this is worth going to a
> new major release.
>

We should definitely add a *loud* statement in the release notes then and
directions for how to work around because I am sure a lot of downstream
builds will fail due to this as DBCP did.  Is there no way that we can
somehow keep the source compatability?  Pool is widely used and a lot of
builds will break IIUC what is going on here.

Phil

>
> I have POOL projects that will benefit (greatly IMO) from cleaner exception
> handling and avoid having to throw/propagate Exception or catch/rethrow
> Exception as a domain Exception, and will now instead be able to use domain
> specific exception for resources being pooled from the get go.
>
> I'll obviously adjust DBCP for this as soon as possible (IOW,
> post-release).
>
> For the other items, I will try and reproduce. My tests builds were ok on
> Windows 10 and macOS latest with Java 8. Maybe by hardware is too slow or
> too fast compared to yours, hard to say.
>
> Gary
>
> On Mon, Jun 26, 2023, 16:53 Phil Steitz  wrote:
>
> > Hi Gary, First, thanks for doing this.  There are a lot of good fixes in
> > here.
> >
> > I checked the build, sigs et al on a couple of platforms and did not
> > find anything major except one item.  I will start with the
> > show-stopper (IMO) and then the other smaller things.
> >
> > 1.  I get compilation failure when I try to compile the latest DBCP
> > release with this code.  I think it may have something to do with
> > POOL-269.  Here is one example:
> >
> > [*ERROR*]
> >
> /Users/psteitz/Downloads/commons-dbcp2-2.9.0-src/src/main/java/org/apache/commons/dbcp2/PoolableConnectionFactory.java:[45,70]
> > wrong number of type arguments; required 2
> >
> > This should not happen in a dot release.
> >
> > 2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure
> > just one time and can't reproduce:
> >
> > java.util.concurrent.ExecutionException:
> > java.lang.NullPointerException: Cannot invoke
> >
> >
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
> > because the return value of "java.util.Map.get(Object)" is null
> >
> > at
> > java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> > at
> > java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> > at
> >
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$2(TestGenericKeyedObjectPool.java:1056)
> > ... 71 more
> > Caused by: java.lang.NullPointerException: Cannot invoke
> >
> >
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
> > because the return value of "java.util.Map.get(Object)" is null
> > at
> >
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addIdleObject(GenericKeyedObjectPool.java:307)
> > at
> >
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.addObject(GenericKeyedObjectPool.java:332)
> > at
> >
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:136)
> > at
> >
> org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:113)
> > at
> >
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$0(TestGenericKeyedObjectPool.java:1036)
> > at
> >
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> > at
> > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> > at
> >
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> > at
> >
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> > at java.base/java.lang.Thread.run(Thread.java:1623)
> >
> > This one is driving me crazy because the NPE should not be possible
> > due to key registration guarding.  I will keep digging on this.
> >
> > 3.
> >
> > I see this one on every run, both config above and Ubuntu 20.0.4 /
> > OpenJDK 11.0.19
> >
> > Exceptio

Re: [VOTE] Release Apache Commons Pool 2.12.0 based on RC1

[Phil Steitz]

Hi Gary, First, thanks for doing this.  There are a lot of good fixes in here.

I checked the build, sigs et al on a couple of platforms and did not
find anything major except one item.  I will start with the
show-stopper (IMO) and then the other smaller things.

1.  I get compilation failure when I try to compile the latest DBCP
release with this code.  I think it may have something to do with
POOL-269.  Here is one example:

[*ERROR*] 
/Users/psteitz/Downloads/commons-dbcp2-2.9.0-src/src/main/java/org/apache/commons/dbcp2/PoolableConnectionFactory.java:[45,70]
wrong number of type arguments; required 2

This should not happen in a dot release.

2. On MacOS 13.4.1, OpenJDK 20.0.1, I got the following test failure
just one time and can't reproduce:

java.util.concurrent.ExecutionException:
java.lang.NullPointerException: Cannot invoke
"org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
because the return value of "java.util.Map.get(Object)" is null

at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at 
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$2(TestGenericKeyedObjectPool.java:1056)
... 71 more
Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getIdleObjects()"
because the return value of "java.util.Map.get(Object)" is null
at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.addIdleObject(GenericKeyedObjectPool.java:307)
at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.addObject(GenericKeyedObjectPool.java:332)
at 
org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:136)
at 
org.apache.commons.pool2.KeyedObjectPool.addObjects(KeyedObjectPool.java:113)
at 
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testConcurrentBorrowAndClear$0(TestGenericKeyedObjectPool.java:1036)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1623)

This one is driving me crazy because the NPE should not be possible
due to key registration guarding.  I will keep digging on this.

3.

I see this one on every run, both config above and Ubuntu 20.0.4 /
OpenJDK 11.0.19

Exception in thread "Thread-1305" org.opentest4j.AssertionFailedError

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:34)

at org.junit.jupiter.api.Assertions.fail(Assertions.java:116)

at 
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.lambda$testClearUnblocksWaiters$3(TestGenericKeyedObjectPool.java:1237)

at java.base/java.lang.Thread.run(Thread.java:1623)

The test that causes it doesn't fail because it happens in a thread
that the test spawns and the test does not wait for the threads it
starts to finish.  Digging into it, I realize this is my sloppiness as
I committed this test case.  I will make a PR to fix it.  I don't
think that it indicates a bug.

4. I forgot to add since tag on the new version of GKOP clear that
adds reuseCapacity parm.  Will fix in the same PR.

5. Small nit.  There is a vestigal paragraph in the release notes
template that I think should be dropped:


No client code changes are required to migrate from versions 2.0-2.3
to version 2.4.3.

Users of version 1.x should consult the migration guide on the Commons
Pool web site.

Phil

On Sat, Jun 24, 2023 at 6:27 PM Gary Gregory  wrote:

> We have fixed quite a few bugs and added some enhancements since
> Apache Commons Pool 2.11.1 was released, so I would like to release
> Apache Commons Pool 2.12.0.
>
> Apache Commons Pool 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.12.0-RC1
> (svn revision 62626)
>
> The Git tag commons-pool-2.12.0-RC1 commit for this RC is
> e5dae53e0ce1211b40680e7dccf601c3c3897378 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=e5dae53e0ce1211b40680e7dccf601c3c3897378
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-pool.git
> --branch 
> commons-pool-2.12.0-RC1 commons-pool-2.12.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1640/org/apache/commons/commons-pool2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jun 24 21:12:18 EDT 2023
>
> commons-pool2-2.12.0-bin.tar.gz=e1

Re: can we get rid of dependabot?

[Phil Steitz]

 Tompkins 

a

écrit :

Guys. I think dependabot is our greatest advantage in the work

against

security problems. I know she has her failings and is chatty.

But, I

think

we should open a line of thinking about how best she can help.

The reason she’s a pain in the ass is that we don’t have enough

hands on

the project making it better. I know I would help more, but I

have

to

keep

up with my father who’s a quadriplegic as well as a currently

failing

marriage.

The answer is that we need more hands on the project. I wish I

could be

those hands but time and priorities keep me chained.

Cheers,
-Rob


On Dec 29, 2021, at 8:26 AM, Gilles Sadowski <

gillese...@gmail.com

wrote:

Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl 

a

écrit

:

+1
Thank you, Phil. This thing is a P.I.T.A.

In effect, from day one:
  https://markmail.org/message/2vutc4p3b3eqv73f

Basically, the argument is that
* the (dependabot) feature is too important to be disabled
* the annoyed people should filter out those mails (which I
did since no one at the time supported that they be diverted
to another ML).
Did anything change since then?
[Or do we eventually question the general anomaly that code
discussions have been almost completely off-loaded to GH?]

Gilles


Am 28.12.2021 um 19:20 schrieb Phil Steitz <

phil.ste...@gmail.com>:

I can no longer effectively monitor commits@ due to the spam

generated by this tool.  I am afraid my eyeballs aren't the only

ones

going

missing here and that is a problem much more severe than any

value

provided

by this tool, IMO.

Phil

Bye, Thomas



-

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

can we get rid of dependabot?

[Phil Steitz]

I can no longer effectively monitor commits@ due to the spam generated 
by this tool.  I am afraid my eyeballs aren't the only ones going 
missing here and that is a problem much more severe than any value 
provided by this tool, IMO.


Phil

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

Re: [pool] BalancedKeyedObjectPool

[Phil Steitz]

On 11/16/21 6:30 AM, Gary Gregory wrote:

Hi Phil.

Sounds interesting.

Would the new API KOP.borrowObject() throw if not configured with a
load balancing policy or would there be a default policy?


I was thinking round-robin would be the default.  If there are no keyed 
pools, I would expect to throw NSEE.


Phil


Gary

On Sun, Nov 14, 2021 at 2:29 PM Phil Steitz  wrote:

Recently I had a the following need, which I have seen on the user list
a few times over the years.

I have a list of resource provider instances that I want to maintain
pools of connections to and I want to load balance connection requests
across the pools.  I can back this using GKOP, but load balancing has to
be done on the client side.  What would be nice would be to have a KOP
that supports borrowing with no key argument and configurable load
balancing strategy (e.g. round-robin, least-loaded, random).

Does this seem like a good addition to [pool]?  Anyone else want to work
on it?

Phil

-
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: [pool] GenericKeyedObjectPool liveness

[Phil Steitz]

On 11/16/21 6:34 AM, Gary Gregory wrote:

Hi Phil,

My only concern is what exactly is (my emphasis)  "When configured to
*globally* optimize resources (new config option),"?

Is this a static variable somewhere? I hope it would not because I do not
want to debug a customer set up one day where where one corner of an app needs
one setting and another a different one.


This would be a suitably named config property - possibly several or an 
enum-valued thing.  GKOP half does this now in an inconsistent and not 
client-fair way.  What I mean by "globally optimize resources" is the 
kind of thing that clearOldest does - trying to use "idle" capacity in 
keyed pools to meet the needs of borrowers waiting on other keys.  The 
situation you describe above is present now and is the cause of a lot of 
the liveness issues reported and hacks like clearOldest and 
reuseCapacity.  I am not sure how best to set up explicit configs, but 
what we have now is neither consistent nor even well-documented.  I 
would at least like to allow users to turn off attempts at global 
optimization entirely.  That would certainly improve throughput in GKOPs 
that don't care about optimizing across pools.


Phil


TY!
Gary


On Sun, Nov 14, 2021 at 1:29 PM Phil Steitz  wrote:


Looking at POOL-350, I realized that we don't really have a coherent
strategy for handling liveness issues in GKOP.  We have been playing
whack-a-mole with problems resulting from two facts about how GKOP works:

  1. There are two capacity constraints that bind on individual keyed
 pools at different times:  total instance count and total per key.
  2. Borrowers waiting on keyed pools have no way to know when capacity
 exists to create new instances.  They have to wait for new instances
 to be added to the LinkedBlockingDeques that they are waiting on.

To (partially) work around 2, we added two methods.  First, clearOldest,
called by borrowObject when no instances are available for the given
key, creates make capacity by clearing the oldest idle instances across
all of the keyed pools.  This makes it less likely that a borrower will
park waiting when overall capacity exists to create an instance under
the desired key. Second, reuseCapacity, called by returnObject and
invalidateObject, tries to create an instance in the most heavily loaded
pool that can add an instance.  These both help reduce the incidence of
borrowers waiting when instances could be created to serve them, but
they don't handle all cases and as reported in POOL-350, when there are
a lot of pools, they can cause performance problems.

I think we need to agree on some principles before continuing to patch
liveness issues in GKOP.  I hope we can lazily agree with:

0) Users should be able to turn off all optimizations that look across
keyed pools (e.g. reuseCapacity, clearOdest).  With these things turned
off, liveness at the individual keyed pool level should work like GOP
(failed validations, invalidate, etc trigger creates under the same key).
1) New borrowers should not take precedence over waiting threads when
capacity exists to create new instances.
2) When configured to globally optimize resources (new config option),
GKOP should decide on each return, invalidate, evict (anything that
passivates or destroys an instance) where to allocate the newly
available capacity.  How exactly this works should be configurable.

None of these are true in the code today.  Note that 2) means that when
instances are returned, they may not be added to their returning idle
instance pools.  That is basically what clearOldest is doing ad hoc only
for new borrowers.

Please anyone interested - especially users - let me know what you think
of 0)-2).  If we can agree on them, we can refactor to make the code
consistent with the principles.

Phil






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

[pool] BalancedKeyedObjectPool

[Phil Steitz]

Recently I had a the following need, which I have seen on the user list 
a few times over the years.


I have a list of resource provider instances that I want to maintain 
pools of connections to and I want to load balance connection requests 
across the pools.  I can back this using GKOP, but load balancing has to 
be done on the client side.  What would be nice would be to have a KOP 
that supports borrowing with no key argument and configurable load 
balancing strategy (e.g. round-robin, least-loaded, random).


Does this seem like a good addition to [pool]?  Anyone else want to work 
on it?


Phil

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

Re: [STATISTICS] Distribution support is connect

[Phil Steitz]

On 11/14/21 2:29 AM, Alex Herbert wrote:

Both the discrete and continuous distribution have a property in the interface:

 /**
  * Indicates whether the support is connected, i.e. whether
  * all values between the lower and upper bound of the support
  * are included in the support.
  *
  * @return whether the support is connected.
  */
 boolean isSupportConnected();

This is only ever true for all distributions.

Other stats libraries in Python, R, Matlab, Mathematica do not have
this property. The property is in commons Math3 and dates back 10
years to the package name change from Math2 to Math3. I did not chase
the commit history through SVN.

In Math3 only 5 real distributions and 1 discrete distribution test
this property. They all test it is true.

Interestingly the discrete distribution is the enumerated distribution
built from a set of discrete values. This may be a case for returning
false if certain values between the lower and upper range have a
probability of zero. But in this case it is valid behaviour to return
zero for the probability.

It may be that this property was intended to be used to determine if
the distribution would throw an exception for certain values between
the lower and upper range for the support. In the [Statistics] version
of the distributions no exceptions are thrown. The return will be
either an appropriate extreme (+/- infinity) or NaN. There is also no
facility to determine what values within the support are not valid. So
the property isSupportConnect alone cannot be used to determine if the
value you are interested in is part of the support. This would require
a isSupported(double x) method.


The reason it exists is to make the default inverse cum impl handle the 
case where there is a gap in support.  If you want to add the 
requirement that support is always connected, you can drop the code in 
the default inverse cum that does this.


Phil


I propose to remove this unused property from the distribution
interfaces prior to the initial 1.0 release to avoid this redundant
method.

Alex

-
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

[pool] GenericKeyedObjectPool liveness

[Phil Steitz]

Looking at POOL-350, I realized that we don't really have a coherent 
strategy for handling liveness issues in GKOP.  We have been playing 
whack-a-mole with problems resulting from two facts about how GKOP works:


1. There are two capacity constraints that bind on individual keyed
   pools at different times:  total instance count and total per key.
2. Borrowers waiting on keyed pools have no way to know when capacity
   exists to create new instances.  They have to wait for new instances
   to be added to the LinkedBlockingDeques that they are waiting on.

To (partially) work around 2, we added two methods.  First, clearOldest, 
called by borrowObject when no instances are available for the given 
key, creates make capacity by clearing the oldest idle instances across 
all of the keyed pools.  This makes it less likely that a borrower will 
park waiting when overall capacity exists to create an instance under 
the desired key. Second, reuseCapacity, called by returnObject and 
invalidateObject, tries to create an instance in the most heavily loaded 
pool that can add an instance.  These both help reduce the incidence of 
borrowers waiting when instances could be created to serve them, but 
they don't handle all cases and as reported in POOL-350, when there are 
a lot of pools, they can cause performance problems.


I think we need to agree on some principles before continuing to patch 
liveness issues in GKOP.  I hope we can lazily agree with:


0) Users should be able to turn off all optimizations that look across 
keyed pools (e.g. reuseCapacity, clearOdest).  With these things turned 
off, liveness at the individual keyed pool level should work like GOP 
(failed validations, invalidate, etc trigger creates under the same key).
1) New borrowers should not take precedence over waiting threads when 
capacity exists to create new instances.
2) When configured to globally optimize resources (new config option), 
GKOP should decide on each return, invalidate, evict (anything that 
passivates or destroys an instance) where to allocate the newly 
available capacity.  How exactly this works should be configurable.


None of these are true in the code today.  Note that 2) means that when 
instances are returned, they may not be added to their returning idle 
instance pools.  That is basically what clearOldest is doing ad hoc only 
for new borrowers.


Please anyone interested - especially users - let me know what you think 
of 0)-2).  If we can agree on them, we can refactor to make the code 
consistent with the principles.


Phil

Re: [compress] Dealing with uncaught RuntimeExceptions (again)

[Phil Steitz]

On 6/29/21 8:08 AM, Stefan Bodewig wrote:

On 2021-06-29, Miguel Munoz wrote:


Catching all RuntimeExceptions and wrapping them in an IOException
looks like the cleanest solution. RuntimeExceptions usually mean bugs,
so if the archive code is throwing them due to a corrupted archive, it
makes sense to wrap it in a checked exception. I would like to suggest
creating a new class looking something like this:
public class CorruptedArchiveException extends IOException { }

https://github.com/apache/commons-compress/compare/catch-RuntimeExceptions

+1
As a user, this is what I would like to see.   I especially like the 
class javadoc :)


Phil


:-)

Stefan

-
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: [commons-pool] branch master updated: [POOL-395] Improve exception thrown in GenericObjectPool.borrowObject when pool is exhausted. Added BaseGenericObjectPool.setMessagesStatistics(boolean).

[Phil Steitz]

It's hard to tell what the actual change is below with all of the 
formatting / cosmetic changes mixed it, but AFAICT there is no sync 
control to ensure consistency or currency of the stats reported. Some 
note in javadoc or somewhere should be added to make it clear that stats 
may not accurately reflect snapshot state at the time of the exception.  
If you want to get a guaranteed accurate snapshot, you would have to 
lock the pool when you take it, which we don't want to do.


On 6/27/21 7:47 AM, ggreg...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

ggregory pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-pool.git


The following commit(s) were added to refs/heads/master by this push:
  new 26b0829  [POOL-395] Improve exception thrown in 
GenericObjectPool.borrowObject when pool is exhausted. Added 
BaseGenericObjectPool.setMessagesStatistics(boolean).
26b0829 is described below

commit 26b0829fef39729df84adb1c01eb55c944aff6d7
Author: Gary Gregory 
AuthorDate: Sun Jun 27 10:47:03 2021 -0400

 [POOL-395] Improve exception thrown in GenericObjectPool.borrowObject
 when pool is exhausted. Added
 BaseGenericObjectPool.setMessagesStatistics(boolean).
 
 - Pick up Checkstyle LineLength module from Commons IO where there was

 none before.
 - Message sentences start with a capital letter.
 - Better parameter names.
 - Javadoc.
 - Inline comments.
---
  checkstyle.xml |   4 +
  src/changes/changes.xml|   3 +
  .../org/apache/commons/pool2/KeyedObjectPool.java  |   4 +-
  .../commons/pool2/KeyedPooledObjectFactory.java|   4 +-
  .../java/org/apache/commons/pool2/ObjectPool.java  |   4 +-
  .../apache/commons/pool2/PooledObjectFactory.java  |   4 +-
  .../commons/pool2/impl/BaseGenericObjectPool.java  | 114 -
  .../commons/pool2/impl/GenericKeyedObjectPool.java |  48 +
  .../commons/pool2/impl/GenericObjectPool.java  |  46 +
  .../pool2/impl/SoftReferenceObjectPool.java|   4 +-
  .../pool2/TestBasePoolableObjectFactory.java   |   4 +-
  .../pool2/impl/TestAbandonedKeyedObjectPool.java   |   4 +-
  .../pool2/impl/TestAbandonedObjectPool.java|   4 +-
  .../pool2/impl/TestGenericKeyedObjectPool.java |  64 +++-
  .../commons/pool2/impl/TestGenericObjectPool.java  |  28 -
  15 files changed, 230 insertions(+), 109 deletions(-)

diff --git a/checkstyle.xml b/checkstyle.xml
index dca770b..3f884e1 100644
--- a/checkstyle.xml
+++ b/checkstyle.xml
@@ -74,4 +74,8 @@
  

  
+  

+
+  
+
  
diff --git a/src/changes/changes.xml b/src/changes/changes.xml
index 40ef624..2368098 100644
--- a/src/changes/changes.xml
+++ b/src/changes/changes.xml
@@ -69,6 +69,9 @@ The  type attribute can be add,update,fix,remove.
  
Handle validation exceptions during eviction. #85.
  
+
+  Improve exception thrown in GenericObjectPool.borrowObject when pool is 
exhausted. Added BaseGenericObjectPool.setMessagesStatistics(boolean).
+
  
  
Fix [WARNING] Old version of checkstyle detected. Consider updating to 
>= v8.30. Update Checktyle to 8.43.
diff --git a/src/main/java/org/apache/commons/pool2/KeyedObjectPool.java 
b/src/main/java/org/apache/commons/pool2/KeyedObjectPool.java
index ab52908..cac55ac 100644
--- a/src/main/java/org/apache/commons/pool2/KeyedObjectPool.java
+++ b/src/main/java/org/apache/commons/pool2/KeyedObjectPool.java
@@ -289,12 +289,12 @@ public interface KeyedObjectPool extends Closeable {
   *
   * @param key the key used to obtain the object
   * @param obj a {@link #borrowObject borrowed} instance to be returned.
- * @param mode destroy activation context provided to the factory
+ * @param destroyMode destroy activation context provided to the factory
   *
   * @throws Exception if the instance cannot be invalidated
   * @since 2.9.0
   */
-default void invalidateObject(final K key, final V obj, final DestroyMode 
mode) throws Exception {
+default void invalidateObject(final K key, final V obj, final DestroyMode 
destroyMode) throws Exception {
  invalidateObject(key, obj);
  }
  
diff --git a/src/main/java/org/apache/commons/pool2/KeyedPooledObjectFactory.java b/src/main/java/org/apache/commons/pool2/KeyedPooledObjectFactory.java

index ac93114..a7f75a3 100644
--- a/src/main/java/org/apache/commons/pool2/KeyedPooledObjectFactory.java
+++ b/src/main/java/org/apache/commons/pool2/KeyedPooledObjectFactory.java
@@ -117,7 +117,7 @@ public interface KeyedPooledObjectFactory {
   *
   * @param key the key used when selecting the instance
   * @param p a {@code PooledObject} wrapping the instance to be destroyed
- * @param mode DestroyMode providing context to the factory
+ * @param destroyMode DestroyMode providing context to the 

Re: [commons-dbcp] 03/09: Use for-each loops

[Phil Steitz]

First, many thanks for the cleanup work.

One thing to bear in mind for the loop changes is that in some cases the 
underlying collections may be changing as the loops progress. In theory, 
unit tests should pick up any problems introduced, but we should look 
carefully at this.


Phil

On 12/4/20 6:15 AM, ebo...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

ebourg pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git

commit 309e204345a7b5181c883b6aa2d8497313f625ef
Author: Emmanuel Bourg 
AuthorDate: Fri Dec 4 13:32:19 2020 +0100

 Use for-each loops
---
  .../java/org/apache/commons/dbcp2/DelegatingConnection.java  |  5 +
  .../dbcp2/datasources/InstanceKeyDataSourceFactory.java  | 12 +++-
  2 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java 
b/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
index bdceb41..e7aeb61 100644
--- a/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
+++ b/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
@@ -36,7 +36,6 @@ import java.sql.Statement;
  import java.sql.Struct;
  import java.util.ArrayList;
  import java.util.Collections;
-import java.util.Iterator;
  import java.util.List;
  import java.util.Map;
  import java.util.Properties;
@@ -620,9 +619,7 @@ public class DelegatingConnection 
extends AbandonedTrace i
  final List traces = getTrace();
  if (traces != null && !traces.isEmpty()) {
  final List thrownList = new ArrayList<>();
-final Iterator traceIter = traces.iterator();
-while (traceIter.hasNext()) {
-final Object trace = traceIter.next();
+for (Object trace : traces) {
  if (trace instanceof Statement) {
  try {
  ((Statement) trace).close();
diff --git 
a/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
 
b/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
index f6ee923..8be3df3 100644
--- 
a/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
+++ 
b/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
@@ -21,7 +21,6 @@ import java.io.IOException;
  import java.io.ObjectInputStream;
  import java.util.ArrayList;
  import java.util.Hashtable;
-import java.util.Iterator;
  import java.util.List;
  import java.util.Map;
  import java.util.Map.Entry;
@@ -47,9 +46,7 @@ abstract class InstanceKeyDataSourceFactory implements 
ObjectFactory {
  
  static synchronized String registerNewInstance(final InstanceKeyDataSource ds) {

  int max = 0;
-final Iterator iterator = instanceMap.keySet().iterator();
-while (iterator.hasNext()) {
-final String s = iterator.next();
+for (String s : instanceMap.keySet()) {
  if (s != null) {
  try {
  max = Math.max(max, Integer.parseInt(s));
@@ -84,13 +81,10 @@ abstract class InstanceKeyDataSourceFactory implements 
ObjectFactory {
  public static void closeAll() throws Exception {
  // Get iterator to loop over all instances of this data source.
  final List exceptionList = new 
ArrayList<>(instanceMap.size());
-final Iterator> instanceIterator 
= instanceMap.entrySet().iterator();
-while (instanceIterator.hasNext()) {
+for (Entry next : 
instanceMap.entrySet()) {
  // Bullet-proof to avoid anything else but problems from 
InstanceKeyDataSource#close().
-final Entry next = 
instanceIterator.next();
  if (next != null) {
-@SuppressWarnings("resource")
-final InstanceKeyDataSource value = next.getValue();
+@SuppressWarnings("resource") final InstanceKeyDataSource 
value = next.getValue();
  if (value != null) {
  try {
  value.close();




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

Re: How to run Test cases of Apache Commons Lang in Intellij?

[Phil Steitz]

On 12/1/20 3:19 AM, Kanak Sony wrote:

Hey Developers,

I have been trying to debug the library in Intellij and in respect to that
trying to run test cases of Apache Commons Lang in intellij but I was
unable to find the same. Can anyone of you please suggest me if any such
resources are available?


Like most other Commons components, [lang] is set up as a maven 
project.  If you configure it as a maven project in Intellij, you can 
execute the tests in the IDE.  See [1].  That said, you can also just 
execute the tests from the command line, by entering "mvn clean test" 
from the top-level directory where you have the code checked out (the 
directory containing the file named pom.xml).  See [2] for an intro to 
maven.


Phil

[1] https://www.jetbrains.com/help/idea/maven-support.html

[2] https://maven.apache.org/guides/getting-started/



--
Regards,
Kanak Sony



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

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 9/23/20 2:57 PM, Gary Gregory wrote:

This all sounds reasonable but it would be easier to see in a PR.


I will do that once the new version of [pool] is released. Otherwise, I 
would have to add snapshot dependency, which I am sure would cause CI to 
fail.


Phil



Gary

On Tue, Sep 22, 2020 at 8:30 PM Phil Steitz  wrote:


On 9/14/20 10:10 AM, Gary Gregory wrote:

On Mon, Sep 14, 2020 at 1:07 PM Phil Steitz 

wrote:

On 9/14/20 9:36 AM, Gary Gregory wrote:

This feature is now in Pool master. I will prepare an RC soon if you
all think we are good to go so we can then move on to DBCP.

I am still working on testing this in the DBCP use case. Probably best
to wait a little for others to review and for me to get the DBCP change
tested against current pool sources.  I should be able to finish that
this weekend.

I implemented changes in DBCP, based on recently committed changes in
pool.  I made a few decisions that I would appreciate feedback on.

1. The JDBC abort method requires an Executor as actual parameter.  I
added a FixedThreadPool executor with a max of 3 threads to
PoolableConnectionFactory for this purpose.  Given that this operation
might hang sometimes, I thought it best to allow more than a single
thread.  I guess it could be configurable, but 3 seemed a reasonable
choice.  I copied the custom thread factory used by pool's EvictionTimer
to source daemon threads based on ccl for this.  I then added a close()
method to PCF that closes the executor and modified BasicDataSource
close to call this.

2. I used p.getObject().getInnermostDelegate().abort(executor) in PCF
destroyObject when abandoned mode is passed in rather than just
getObject().abort as destroy invokes close (I wonder if that is a bug?)

3. I changed JdbcBridge#abort to remove the checkOpen() check.  I was
getting exceptions in my concurrency tests where connections were being
closed but then considered abandoned.  This is a legit race that abort
will generally handle fine and I don't see the need to throw.

Phil


Sounds good.

Gary


Phil


Gary

On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory 

wrote:

FWIW, I like the name "DestroyMode" because it matches the "destroy"

in the method name.

Gary

On Mon, Sep 7, 2020, 19:08 Gary Gregory 

wrote:

On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz 

wrote:

On 9/3/20 2:44 AM, Mark Thomas wrote:

On 31/08/2020 01:05, Phil Steitz wrote:




If others agree it is a good idea for dbcp, I can do it.  I can

see the

argument that its better to stay with close() even for abandoned

and I

have not been able to get the deadlock to happen, so I would like

to

wait a bit and allow others to weigh in.  Similarly for pool, I

would

like to get more community feedback before adding to the

interface.

Hmm.

On one hand if the driver deadlocks I don't see how that can be

anything

other than a driver bug. If multiple code paths obtain multiple

locks

then those code paths must always obtain those locks in the same

order.

Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.

On the other hand, it could be argued that the situation only

arises

when an application doesn't correctly return connections to the

pool

and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.

The approach of adding

PooledObjectFactory.destroyObject(PooledObject,CloseMode)

where CloseMode is an Enum with two values looks reasonable to me.

I have started to work on the [pool] changes for this.  I want to

check

two things before completing the PR:

1.  "Close" is a [dbcp] concept which does not make sense for all

pool

factories, so I am going to name the enum "DestroyMode" and the two
modes, "Default" and "Abandoned".  That leaves room for other modes

like

"Evicted" or "Invalid" later.

2. Speaking of later, technically adding modes will not break binary
compatibility.  Are we going to be OK adding outside a major

release?

If the answer is no, I might argue to include the other natural

modes now.

Yes, IMO, it is OK to add enum values in a minor release since it

does

not break binary (or source) compatibility.

Gary


Phil


I do agree that abort() should only be used in the case of

abandoned

connections.

Mark



-

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: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 9/14/20 10:10 AM, Gary Gregory wrote:

On Mon, Sep 14, 2020 at 1:07 PM Phil Steitz  wrote:


On 9/14/20 9:36 AM, Gary Gregory wrote:

This feature is now in Pool master. I will prepare an RC soon if you
all think we are good to go so we can then move on to DBCP.

I am still working on testing this in the DBCP use case. Probably best
to wait a little for others to review and for me to get the DBCP change
tested against current pool sources.  I should be able to finish that
this weekend.


I implemented changes in DBCP, based on recently committed changes in 
pool.  I made a few decisions that I would appreciate feedback on.


1. The JDBC abort method requires an Executor as actual parameter.  I 
added a FixedThreadPool executor with a max of 3 threads to 
PoolableConnectionFactory for this purpose.  Given that this operation 
might hang sometimes, I thought it best to allow more than a single 
thread.  I guess it could be configurable, but 3 seemed a reasonable 
choice.  I copied the custom thread factory used by pool's EvictionTimer 
to source daemon threads based on ccl for this.  I then added a close() 
method to PCF that closes the executor and modified BasicDataSource 
close to call this.


2. I used p.getObject().getInnermostDelegate().abort(executor) in PCF 
destroyObject when abandoned mode is passed in rather than just 
getObject().abort as destroy invokes close (I wonder if that is a bug?)


3. I changed JdbcBridge#abort to remove the checkOpen() check.  I was 
getting exceptions in my concurrency tests where connections were being 
closed but then considered abandoned.  This is a legit race that abort 
will generally handle fine and I don't see the need to throw.


Phil


Sounds good.

Gary


Phil


Gary

On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory  wrote:

FWIW, I like the name "DestroyMode" because it matches the "destroy" in the 
method name.

Gary

On Mon, Sep 7, 2020, 19:08 Gary Gregory  wrote:

On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz  wrote:

On 9/3/20 2:44 AM, Mark Thomas wrote:

On 31/08/2020 01:05, Phil Steitz wrote:




If others agree it is a good idea for dbcp, I can do it.  I can see the
argument that its better to stay with close() even for abandoned and I
have not been able to get the deadlock to happen, so I would like to
wait a bit and allow others to weigh in.  Similarly for pool, I would
like to get more community feedback before adding to the interface.

Hmm.

On one hand if the driver deadlocks I don't see how that can be anything
other than a driver bug. If multiple code paths obtain multiple locks
then those code paths must always obtain those locks in the same order.
Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.

On the other hand, it could be argued that the situation only arises
when an application doesn't correctly return connections to the pool
and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.

The approach of adding

PooledObjectFactory.destroyObject(PooledObject,CloseMode)

where CloseMode is an Enum with two values looks reasonable to me.

I have started to work on the [pool] changes for this.  I want to check
two things before completing the PR:

1.  "Close" is a [dbcp] concept which does not make sense for all pool
factories, so I am going to name the enum "DestroyMode" and the two
modes, "Default" and "Abandoned".  That leaves room for other modes like
"Evicted" or "Invalid" later.

2. Speaking of later, technically adding modes will not break binary
compatibility.  Are we going to be OK adding outside a major release?
If the answer is no, I might argue to include the other natural modes now.

Yes, IMO, it is OK to add enum values in a minor release since it does
not break binary (or source) compatibility.

Gary


Phil


I do agree that abort() should only be used in the case of abandoned
connections.

Mark

-
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



-

Re: [DBCP] Release 2.8.0

[Phil Steitz]

Sounds good.  I implemented the DBCP changes this weekend but did not 
finish testing and I had to make some decisions that would be good to 
talk about.  I will ask about that in another thread.  I think the pool 
changes are fine though and will meet the need.


On 9/21/20 7:55 AM, Gary Gregory wrote:

Hi All:

I need to pick up the fix "Mask out user name and password from
DriverAdapterCPDS.toString()." ASAP, so I plan on creating a release
candidate later today or tonight.

I can pick up the new DestroyMode work Phil did in Pool for use in DBCP in
a subsequent release.

Gary



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

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 9/14/20 9:36 AM, Gary Gregory wrote:

This feature is now in Pool master. I will prepare an RC soon if you
all think we are good to go so we can then move on to DBCP.


I am still working on testing this in the DBCP use case. Probably best 
to wait a little for others to review and for me to get the DBCP change 
tested against current pool sources.  I should be able to finish that 
this weekend.


Phil



Gary

On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory  wrote:

FWIW, I like the name "DestroyMode" because it matches the "destroy" in the 
method name.

Gary

On Mon, Sep 7, 2020, 19:08 Gary Gregory  wrote:

On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz  wrote:


On 9/3/20 2:44 AM, Mark Thomas wrote:

On 31/08/2020 01:05, Phil Steitz wrote:




If others agree it is a good idea for dbcp, I can do it.  I can see the
argument that its better to stay with close() even for abandoned and I
have not been able to get the deadlock to happen, so I would like to
wait a bit and allow others to weigh in.  Similarly for pool, I would
like to get more community feedback before adding to the interface.

Hmm.

On one hand if the driver deadlocks I don't see how that can be anything
other than a driver bug. If multiple code paths obtain multiple locks
then those code paths must always obtain those locks in the same order.
Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.

On the other hand, it could be argued that the situation only arises
when an application doesn't correctly return connections to the pool
and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.

The approach of adding

PooledObjectFactory.destroyObject(PooledObject,CloseMode)

where CloseMode is an Enum with two values looks reasonable to me.


I have started to work on the [pool] changes for this.  I want to check
two things before completing the PR:

1.  "Close" is a [dbcp] concept which does not make sense for all pool
factories, so I am going to name the enum "DestroyMode" and the two
modes, "Default" and "Abandoned".  That leaves room for other modes like
"Evicted" or "Invalid" later.

2. Speaking of later, technically adding modes will not break binary
compatibility.  Are we going to be OK adding outside a major release?
If the answer is no, I might argue to include the other natural modes now.

Yes, IMO, it is OK to add enum values in a minor release since it does
not break binary (or source) compatibility.

Gary


Phil


I do agree that abort() should only be used in the case of abandoned
connections.

Mark

-
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: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 9/3/20 2:44 AM, Mark Thomas wrote:

On 31/08/2020 01:05, Phil Steitz wrote:




If others agree it is a good idea for dbcp, I can do it.  I can see the
argument that its better to stay with close() even for abandoned and I
have not been able to get the deadlock to happen, so I would like to
wait a bit and allow others to weigh in.  Similarly for pool, I would
like to get more community feedback before adding to the interface.

Hmm.

On one hand if the driver deadlocks I don't see how that can be anything
other than a driver bug. If multiple code paths obtain multiple locks
then those code paths must always obtain those locks in the same order.
Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.

On the other hand, it could be argued that the situation only arises
when an application doesn't correctly return connections to the pool
and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.

The approach of adding

PooledObjectFactory.destroyObject(PooledObject,CloseMode)

where CloseMode is an Enum with two values looks reasonable to me.



I have started to work on the [pool] changes for this.  I want to check 
two things before completing the PR:


1.  "Close" is a [dbcp] concept which does not make sense for all pool 
factories, so I am going to name the enum "DestroyMode" and the two 
modes, "Default" and "Abandoned".  That leaves room for other modes like 
"Evicted" or "Invalid" later.


2. Speaking of later, technically adding modes will not break binary 
compatibility.  Are we going to be OK adding outside a major release?  
If the answer is no, I might argue to include the other natural modes now.


Phil



I do agree that abort() should only be used in the case of abandoned
connections.

Mark

-
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: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 9/3/20 3:02 PM, Bernd Eckenfels wrote:

The issues I have seen are not a/b "deadlocks", they are "just" endless locks - 
the close is waiting for a read to finish (since both synchronize on the connection). If the 
asumption is a pool timer can in the background cancel a read - it can't, at least on Oracle thin 
or jtds.

The cause can be softened by using read timeouts and/or keepalive, but both is 
not the default and can block the pool for minutes, still.



The question is would using abort instead of close work better in some 
of the abandoned connection scenarios.  IIUC the contract correctly, at 
least the pool thread will not be blocked in these scenarios if we move 
to this for that use case.  Note that dbcp/pool can be configured to 
remove abandoned connections on borrow as well as maintenance, so 
blocking in the former case blocks the pool client.


Phil



Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Mark Thomas 
Gesendet: Thursday, September 3, 2020 11:44:52 AM
An: dev@commons.apache.org 
Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections?

On 31/08/2020 01:05, Phil Steitz wrote:




If others agree it is a good idea for dbcp, I can do it.  I can see the
argument that its better to stay with close() even for abandoned and I
have not been able to get the deadlock to happen, so I would like to
wait a bit and allow others to weigh in.  Similarly for pool, I would
like to get more community feedback before adding to the interface.

Hmm.

On one hand if the driver deadlocks I don't see how that can be anything
other than a driver bug. If multiple code paths obtain multiple locks
then those code paths must always obtain those locks in the same order.
Anything else is a bug that is likely to result in a deadlock in a
multithreaded environment.

On the other hand, it could be argued that the situation only arises
when an application doesn't correctly return connections to the pool
and/or keeps them for too long and/or doesn't configure the pool
correctly for their usage pattern.

The approach of adding

PooledObjectFactory.destroyObject(PooledObject,CloseMode)

where CloseMode is an Enum with two values looks reasonable to me.

I do agree that abort() should only be used in the case of abandoned
connections.

Mark

-
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: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 8/30/20 4:00 PM, Gary Gregory wrote:

On Sun, Aug 30, 2020 at 2:30 PM Phil Steitz  wrote:


On 8/30/20 9:22 AM, Gary Gregory wrote:

Hm... would we need the flexibility of passing custom enums? For example,
CloseMode could be an interface implemented by various enums in the style
of the JRE's NIO public enum StandardOpenOption implements OpenOption?
We could have:
PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)

Remember this is only called by the pool, so I don't see the need for
custom enums, but it would be good to be able to add enum values so as
you suggested we start with the simplest but then add more granularity
as needed.


Phil,

Do you plan on providing this feature? I'm a bit busy with other components
and work ATM (aren't we all!)
If others agree it is a good idea for dbcp, I can do it.  I can see the 
argument that its better to stay with close() even for abandoned and I 
have not been able to get the deadlock to happen, so I would like to 
wait a bit and allow others to weigh in.  Similarly for pool, I would 
like to get more community feedback before adding to the interface.


Phil


Gary


Phil


Where DestroyOption is an empty interface and we provide a
StandardDestroyOption enum that implements DestroyOption.
?
Gary

On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
wrote:


So concretely, we would
add

org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,

CloseMode*) as a default method.
[*] New enum

?

Gary


On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
wrote:


On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver

bug,

but in [2], the driver maintainer makes the good point that to avoid

the

problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO,

as

it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in

the

Java

8 Javadoc).

Yes, bad idea to do that, I think.


or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it

could

be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real

resource

leak in the sense that (if) abort() leaks database resources, then

the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current

close/destroy

is

OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This

is

similar to what we did in HttpCore's CloseMode(IMMEDIATE vs

GRACEFUL):
https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle

destroy

differently for abandoned (or other) cases.


What I propose is that we make these change to pool:

1. Add a new method to PooledObjectFactory called "abandonObject"

with

   default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would

be

easier to find.

Yes, I think that would be better.  That raises the interesting

question

of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to

support

the new behavior backed by Connection#abort() in DBCP.
A thir

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 8/30/20 9:22 AM, Gary Gregory wrote:

Hm... would we need the flexibility of passing custom enums? For example,
CloseMode could be an interface implemented by various enums in the style
of the JRE's NIO public enum StandardOpenOption implements OpenOption?
We could have:
PooledObjectFactory.destroyObject(PooledObject, DestroyOption*)


Remember this is only called by the pool, so I don't see the need for 
custom enums, but it would be good to be able to add enum values so as 
you suggested we start with the simplest but then add more granularity 
as needed.


Phil


Where DestroyOption is an empty interface and we provide a
StandardDestroyOption enum that implements DestroyOption.
?
Gary

On Sun, Aug 30, 2020 at 11:49 AM Gary Gregory 
wrote:


So concretely, we would
add org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObject,
CloseMode*) as a default method.
[*] New enum

?

Gary


On Sat, Aug 29, 2020 at 4:02 PM Gary Gregory 
wrote:


On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz 
wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid

the

problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO,

as

it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in the

Java

8 Javadoc).

Yes, bad idea to do that, I think.




or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it

could

be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real

resource

leak in the sense that (if) abort() leaks database resources, then the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current close/destroy

is

OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This is
similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):


https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle destroy
differently for abandoned (or other) cases.




What I propose is that we make these change to pool:

   1. Add a new method to PooledObjectFactory called "abandonObject"

with

  default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would be
easier to find.

Yes, I think that would be better.  That raises the interesting question
of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to support
the new behavior backed by Connection#abort() in DBCP.
A third "escape hatch" mode could see passing in a lamba I suppose. I
really think we should start by just focusing on the one issue at hand
before we enlarge the solution.

2c,
Gary



Phil




Gary



   2. Change the logic in removeAbandoned to call the new factory

method

  instead of destroyObject

And then in dbcp:

* Add implementation of abandonObject in PoolableConnectionFactory

to

  call abort.

wdyt?

Phil

[1]



https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomca

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 8/29/20 9:58 PM, Bernd Eckenfels wrote:

We have a pool implementation where we had to call abort especially for revoked 
long running transactions, since they regularly have been locked up in a 
connection wide synchronized in the close. However we only use it for that case 
and try to close the objects after the abort anyway. We don’t use it to close 
connections when they are only idle or too old - owned by the pool.


Right.  I was thinking only of the abandoned case.

Interestingly, I have not been able to replicate the deadlock that 
started me thinking about this.  I have always worried though about 
problems with close hanging or deadlocking in the abandoned use case 
where what is going on is a transaction is stuck or the abandoned 
timeout is just set too low.


Phil



It seems to be however still a good idea to run the abort/close in a separate 
task as it can also take ages for example when TLS close handshakes hang (we 
did try to reduce the connection timeout before but that also can be blocked 
before the abort)

Gruss
Bernd
--
https://Bernd.eckenfels.net

Von: Gary Gregory 
Gesendet: Saturday, August 29, 2020 10:02:42 PM
An: Commons Developers List 
Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections?

On Sat, Aug 29, 2020 at 2:41 PM Phil Steitz  wrote:


On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz 

wrote:

A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid the
problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO, as
it could mess up counters due to async execution and add overhead)

I agree that changing the happy path from close() to abort() is a bad

idea;

especially since the Connection#close() Javadoc contract releases

database

resources while abort() does not or is vague about it (at least in the

Java

8 Javadoc).

Yes, bad idea to do that, I think.




or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it could
be useful for other pool clients to be able to this kind of thing as

well.

This means that we would treat abandoned connections like a real resource
leak in the sense that (if) abort() leaks database resources, then the

DBA

would have to deal with that.

Yeah, unless the driver does it cleanly.  The other thing to note here
is that abort is async and is supposed to allow ops in progress to
complete, etc.  That is kinder to clients but technically allows
maxActive to exceed the cap while the abort is in progress.


I think formally surfacing an abort path vs. the current close/destroy is
OK since it reflects what JDBC allows. If that means trickling the

concept

down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This is
similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):


https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html

Exactly.  I think the abandoned-destroy is legitimately different from
the other destroy use cases and I could see other kinds of pools
(sockets, jms, etc) benefiting from having the ability to handle destroy
differently for abandoned (or other) cases.




What I propose is that we make these change to pool:

   1. Add a new method to PooledObjectFactory called "abandonObject" with
  default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would be
easier to find.

Yes, I think that would be better.  That raises the interesting question
of what are the CloseModes.  All we need for this issue is normal vs
abandoned, but I can see value in providing fuller context to
factories.  So if we are doing it, why not something like:

invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool


I think a YAGNI-style approach would work well here by starting with 2
modes: one to support the current behavior (default) and another to support
the new behavior backed by Connection#abort() in DBCP.
A third "escape hatch" mode could see passing in a lamba I suppose. I
really think we should start by just focusing on the one issue at hand
before we enlarge the solution.

2c,
Gary



Phil




Gary



   2. Change the logic in removeAbandoned to call the new factory method
  inst

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

On 8/29/20 11:03 AM, Gary Gregory wrote:

On Sat, Aug 29, 2020 at 1:35 PM Phil Steitz  wrote:


A pool-related deadlock was reported recently in [1] to tomcat-user.
The OP was using a different pool, but it looks to me like the same
deadlock could happen with dbcp.  The source is arguably a driver bug,
but in [2], the driver maintainer makes the good point that to avoid the
problem in [1] (and others like it) it would be better if pool
maintainers used abort instead of close to disconnect "stuck" or
abandoned connections.  That makes sense to me.

To implement this in dbcp, we would need to either always use abort
instead of close when closing physical connections (a bad idea, IMO, as
it could mess up counters due to async execution and add overhead)


I agree that changing the happy path from close() to abort() is a bad idea;
especially since the Connection#close() Javadoc contract releases database
resources while abort() does not or is vague about it (at least in the Java
8 Javadoc).


Yes, bad idea to do that, I think.





or
modify pool to call a different factory method than destroy when
triggering close-abandoned.  I think the latter makes sense and it could
be useful for other pool clients to be able to this kind of thing as well.


This means that we would treat abandoned connections like a real resource
leak in the sense that (if) abort() leaks database resources, then the DBA
would have to deal with that.


Yeah, unless the driver does it cleanly.  The other thing to note here 
is that abort is async and is supposed to allow ops in progress to 
complete, etc.  That is kinder to clients but technically allows 
maxActive to exceed the cap while the abort is in progress.




I think formally surfacing an abort path vs. the current close/destroy is
OK since it reflects what JDBC allows. If that means trickling the concept
down to Pool, then that's OK as well IMO. This could be generically
surfaced with a "close mode" enum passed to close/destroy APIs. This is
similar to what we did in HttpCore's CloseMode(IMMEDIATE vs GRACEFUL):
https://javadoc.io/static/org.apache.httpcomponents.core5/httpcore5/5.0.1/org/apache/hc/core5/io/CloseMode.html


Exactly.  I think the abandoned-destroy is legitimately different from 
the other destroy use cases and I could see other kinds of pools 
(sockets, jms, etc) benefiting from having the ability to handle destroy 
differently for abandoned (or other) cases.






What I propose is that we make these change to pool:

  1. Add a new method to PooledObjectFactory called "abandonObject" with
 default implementation delegating to destroyObject.


That or overload destroyObject with a destroyObject(CloseMode) would be
easier to find.


Yes, I think that would be better.  That raises the interesting question 
of what are the CloseModes.  All we need for this issue is normal vs 
abandoned, but I can see value in providing fuller context to 
factories.  So if we are doing it, why not something like:


invalidated
abandoned
evicted
excess idle
failed validation
failed activation
failed passivation
clearing pool

Phil





Gary



  2. Change the logic in removeAbandoned to call the new factory method
 instead of destroyObject

And then in dbcp:

   * Add implementation of abandonObject in PoolableConnectionFactory to
 call abort.

wdyt?

Phil

[1]

https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomcat.apache.org%3E

[2] https://bugs.mysql.com/bug.php?id=64954





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

[dbcp][pool] Use abort instead of close for abandoned connections?

[Phil Steitz]

A pool-related deadlock was reported recently in [1] to tomcat-user.  
The OP was using a different pool, but it looks to me like the same 
deadlock could happen with dbcp.  The source is arguably a driver bug, 
but in [2], the driver maintainer makes the good point that to avoid the 
problem in [1] (and others like it) it would be better if pool 
maintainers used abort instead of close to disconnect "stuck" or 
abandoned connections.  That makes sense to me.


To implement this in dbcp, we would need to either always use abort 
instead of close when closing physical connections (a bad idea, IMO, as 
it could mess up counters due to async execution and add overhead) or 
modify pool to call a different factory method than destroy when 
triggering close-abandoned.  I think the latter makes sense and it could 
be useful for other pool clients to be able to this kind of thing as well.


What I propose is that we make these change to pool:

1. Add a new method to PooledObjectFactory called "abandonObject" with
   default implementation delegating to destroyObject.
2. Change the logic in removeAbandoned to call the new factory method
   instead of destroyObject

And then in dbcp:

 * Add implementation of abandonObject in PoolableConnectionFactory to
   call abort.

wdyt?

Phil

[1] 
https://lists.apache.org/thread.html/r7095d641bbc8db0a526d2d9a18684202347a747cf0e315a4a50d2001%40%3Cusers.tomcat.apache.org%3E


[2] https://bugs.mysql.com/bug.php?id=64954

Re: [all] When to update dependencies?

[Phil Steitz]

On 7/24/20 1:04 AM, Stefan Bodewig wrote:

Hi all

here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.

First of all let me get a few things out of the way

* I'm not talking about emails, I can deal with them

* I don't care whether a bot or a human asks for a version update

* I'm only talking about dependencies that are visible to our
   users. Test time dependencies or versions of Maven plugins are
   probably not an issue. Although Compress has mananaged to break its
   OSGi bundle just by upgrading the parent POM in the past.
   https://issues.apache.org/jira/browse/COMPRESS-498

All our components have downstream users. I.e. our dependencies become
somebody else's dependencies as well.

Let's say commons-foo 1.1.0 depends on A 1.12.4 and bumps the dependency
to A 1.12.18 for commons-foo 1.2.0.

When a user of commons-foo upgrades to 1.2.0 and hasn't defined their
dependency on A explicitly they will also upgrade A to 1.12.18. This may
be fine or it may cause problems. The new version of A may have made
incompatible changes that break the user's code or it may just have bugs
that were not present in A 1.12.4 and now raise their head.

Of course the users can explicitly state a dependency on A 1.12.4
themselves. But there is no guarantee commons-foo compiled against A
1.12.18 will still work with A 1.12.4.

About fifteen years ago Ant was bitten by StringBuffer adding a new
method append(StringBuffer) in Java 1.4 (if memory serves me
right). Code that called someStringBuffer.append(anotherStringBuffer)
compiled on Java 1.3 would call append(Object), but compiled on 1.4 it
would call the new version and thus could not run on Java 1.3. This is
the kind of change animal sniffer was invented to detect and the
--release option of javac deals with. There is no such tool helping us
with APIs that are not part of the Java classlib.

Therefore I believe updating a dependency is a risk and we should leave
it to the users to decide which version they want to use.

Unless we've got real reasons to update. Real reasons IMHO are security
issues, bugs in dependencies causing bugs in our code or when we really
want to use new features introduced in a new version.



+1

Above seems a good list of reasons to me.

I would also add that we should try as much as possible to avoid 
dependencies in Commons components.  There is no need to update 
dependencies that don't exist :)  I agree with Gary though that shading 
/ pasting should not be used to avoid dependencies in Commons 
components.  Some can't avoid having dependencies.  When they do, I 
think your criteria for when to update is good.


I agree strongly with the point you make below about the need to care 
more about our downstream users than ourselves or upstream. If we pass 
too many regression or compatibility bugs forward, we will eventually 
lose the former, which makes our components kind of pointless.


I also agree with your view on automatic transitive dependency 
resolution.  Violates what I call the law of conservation of real work.  
But that ship has sailed...


Phil



Outside of these good reasons I wouldn't want to ever update a
dependency.

Stefan

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



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

Re: [pool] Re: [DBCP] testEvict fails

[Phil Steitz]

On 7/8/20 8:33 AM, Gary Gregory wrote:

On Wed, Jul 8, 2020 at 11:20 AM Phil Steitz  wrote:


On 7/5/20 7:08 PM, Phil Steitz wrote:


On 7/5/20 6:02 PM, Phil Steitz wrote:


On 7/5/20 11:07 AM, Phil Steitz wrote:

The test looks a little off to me.  I am not sure I fully understand
what it is trying to do, but I suspect that the reason that it fails
sporadically (I have seen this myself) is that to succeed it needs
to run two evictor cycles when it is set to wait for only one.  I
may be wrong as I don't fully follow the intent or logic of the test.

Looks to me like what it is trying to do is:

  1. Create and force initialization of a BDS with initialsize = 10,
 minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
 timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
  2. Execute a loop whose guard I don't understand that appears to
 wait for an eviction cycle to complete, waiting at least 1
 second between iterations
  3. Expect to see no more than 5 idle connections.

I don't understand the search for eviction threads in the guard in
2.  Just waiting would work if what we are trying to do is to verify
that old connections are being evicted (basically duplicating tests
in [pool]).  In any case, in order to get down to 5, you need to run
2 cycles, because each only visits 3.  It would seem to me that to
make it succeed consistently, you need to either increase
numTestsPerEvictionRun to 5 or have it wait for two cycles.

Phil


I think I now understand the intent of the test and I think that what
it is trying to do points to what may be a [pool] bug.  The post
mentioned in the PR that created this test [1] may be onto something.

It seems odd that closing a GKOP with no evictor can stop the evictor
for a different GOP, but I think it may be possible. I don't have any
more time to dig on this for now, but here is what I think may be
happening:

As the OP stated in [1], the close on the GKOP for the statement pool
calls BaseGOP stopEvictor.  This results in
EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis,
TimeUnit.MILLISECONDS) being called with a evictor null.  This starts
with

if (evictor != null) {
 evictor.cancel();
}
if (executor != null && executor.getQueue().isEmpty()) {
 executor.shutdown();

}

A quick look at the jdk sources for the executor makes me think it is
possible that if there is just one other evictor running and it is in
process of running a task when the test above is performed, the queue
may show as empty because it has taken the queued task, is executing
it and only re-queues afterward.  That could cause the main executor
to be shut down.

To make this happen, it would be best to add some latency to eviction
tasks and have another one open and close a bunch of others with
evictors disabled concurrently.  If this turns out to be correct, a
simple fix would be to just exit immediately if evictor is null (a
null evictor can't be the last one).


Thinking about this some more, the quick exit above will handle the
DBCP statement pool case, but the problem could also happen with
non-null evictors.  So the code probably needs to be modified to live
up to the commitment in the EvictionTimer class javadoc (that it keeps
track of its client pools and shuts down only when they have all shut
down).


I have verified that this is in fact a [pool] bug.  I have a unit test
that shows eviction stopped for an active pool as a result of closing
another pool while an eviction task is executing.  I will open a [pool]
JIRA with the test case later today.  I would expect the [dbcp]
statement pool use case to be where this happens most frequently, so it
may make sense to open a [dbcp] ticket as well, linked to the [pool]
issue.  Agreed?

I think that what is happening is what I describe above.
ScheduledThreadPoolExecutor reports an empty queue when it is executing
a task and only re-queues the next one when the executing instance is
finished.  So if (executor != null && executor.getQueue().isEmpty())
returns true when there is an eviction task in progress.  The best and
simplest fix that I can think of is to add && executor.getActiveCount()
== 0 to the test above.  That makes my test succeed and is almost
complete.  The "almost" is due to the fact that the queue empty and
active count tests are not atomic.


Shouldn't we make this count atomic?


That would be ideal, but I don't see a way to do it.  I wish that 
ScheduledThreadPoolExecutor exposed a "hasTasks" or somesuch property 
that checks the queue length and the active count and returns true iff 
the queue is non-empty or a task is in progress. But there is no such 
property.  And all that we control from our code is when new scheduled 
tasks get submitted and when the whole timer is cancelled.


Phil



Gary



Unfortunately, STPE does not expose
its internal lock so I can't see any way to test atomically.

Re: [pool] Re: [DBCP] testEvict fails

[Phil Steitz]

On 7/5/20 7:08 PM, Phil Steitz wrote:



On 7/5/20 6:02 PM, Phil Steitz wrote:



On 7/5/20 11:07 AM, Phil Steitz wrote:


The test looks a little off to me.  I am not sure I fully understand 
what it is trying to do, but I suspect that the reason that it fails 
sporadically (I have seen this myself) is that to succeed it needs 
to run two evictor cycles when it is set to wait for only one.  I 
may be wrong as I don't fully follow the intent or logic of the test.


Looks to me like what it is trying to do is:

 1. Create and force initialization of a BDS with initialsize = 10,
minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
 2. Execute a loop whose guard I don't understand that appears to
wait for an eviction cycle to complete, waiting at least 1
second between iterations
 3. Expect to see no more than 5 idle connections.

I don't understand the search for eviction threads in the guard in 
2.  Just waiting would work if what we are trying to do is to verify 
that old connections are being evicted (basically duplicating tests 
in [pool]).  In any case, in order to get down to 5, you need to run 
2 cycles, because each only visits 3.  It would seem to me that to 
make it succeed consistently, you need to either increase 
numTestsPerEvictionRun to 5 or have it wait for two cycles.


Phil



I think I now understand the intent of the test and I think that what 
it is trying to do points to what may be a [pool] bug.  The post 
mentioned in the PR that created this test [1] may be onto something.


It seems odd that closing a GKOP with no evictor can stop the evictor 
for a different GOP, but I think it may be possible. I don't have any 
more time to dig on this for now, but here is what I think may be 
happening:


As the OP stated in [1], the close on the GKOP for the statement pool 
calls BaseGOP stopEvictor.  This results in 
EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis, 
TimeUnit.MILLISECONDS) being called with a evictor null.  This starts 
with


if (evictor != null) {
    evictor.cancel();
}
if (executor != null && executor.getQueue().isEmpty()) {
    executor.shutdown();

}

A quick look at the jdk sources for the executor makes me think it is 
possible that if there is just one other evictor running and it is in 
process of running a task when the test above is performed, the queue 
may show as empty because it has taken the queued task, is executing 
it and only re-queues afterward.  That could cause the main executor 
to be shut down.


To make this happen, it would be best to add some latency to eviction 
tasks and have another one open and close a bunch of others with 
evictors disabled concurrently.  If this turns out to be correct, a 
simple fix would be to just exit immediately if evictor is null (a 
null evictor can't be the last one).


Thinking about this some more, the quick exit above will handle the 
DBCP statement pool case, but the problem could also happen with 
non-null evictors.  So the code probably needs to be modified to live 
up to the commitment in the EvictionTimer class javadoc (that it keeps 
track of its client pools and shuts down only when they have all shut 
down).



I have verified that this is in fact a [pool] bug.  I have a unit test 
that shows eviction stopped for an active pool as a result of closing 
another pool while an eviction task is executing.  I will open a [pool] 
JIRA with the test case later today.  I would expect the [dbcp] 
statement pool use case to be where this happens most frequently, so it 
may make sense to open a [dbcp] ticket as well, linked to the [pool] 
issue.  Agreed?


I think that what is happening is what I describe above. 
ScheduledThreadPoolExecutor reports an empty queue when it is executing 
a task and only re-queues the next one when the executing instance is 
finished.  So if (executor != null && executor.getQueue().isEmpty()) 
returns true when there is an eviction task in progress.  The best and 
simplest fix that I can think of is to add && executor.getActiveCount() 
== 0 to the test above.  That makes my test succeed and is almost 
complete.  The "almost" is due to the fact that the queue empty and 
active count tests are not atomic.  Unfortunately, STPE does not expose 
its internal lock so I can't see any way to test atomically. In theory, 
between the two tests, a task could complete and get re-queued, but that 
is highly unlikely.  Any better ideas on the fix?


Phil



Phil

Phil


[1] 
http://mail-archives.apache.org/mod_mbox/commons-user/202004.mbox/%3CCAD1sBYus4-j4i2Fs6dvzv_p4z0kaiu_8Yz8qUwXxTGAKp1ef1g%40mail.gmail.com%3E



On 7/5/20 6:04 AM, Gary Gregory wrote:

This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.

I am guessing the test might need to be set up dif

Re: [pool] Re: [DBCP] testEvict fails

[Phil Steitz]

On 7/5/20 6:02 PM, Phil Steitz wrote:



On 7/5/20 11:07 AM, Phil Steitz wrote:


The test looks a little off to me.  I am not sure I fully understand 
what it is trying to do, but I suspect that the reason that it fails 
sporadically (I have seen this myself) is that to succeed it needs to 
run two evictor cycles when it is set to wait for only one.  I may be 
wrong as I don't fully follow the intent or logic of the test.


Looks to me like what it is trying to do is:

 1. Create and force initialization of a BDS with initialsize = 10,
minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
 2. Execute a loop whose guard I don't understand that appears to
wait for an eviction cycle to complete, waiting at least 1 second
between iterations
 3. Expect to see no more than 5 idle connections.

I don't understand the search for eviction threads in the guard in 
2.  Just waiting would work if what we are trying to do is to verify 
that old connections are being evicted (basically duplicating tests 
in [pool]).  In any case, in order to get down to 5, you need to run 
2 cycles, because each only visits 3.  It would seem to me that to 
make it succeed consistently, you need to either increase 
numTestsPerEvictionRun to 5 or have it wait for two cycles.


Phil



I think I now understand the intent of the test and I think that what 
it is trying to do points to what may be a [pool] bug.  The post 
mentioned in the PR that created this test [1] may be onto something.


It seems odd that closing a GKOP with no evictor can stop the evictor 
for a different GOP, but I think it may be possible.  I don't have any 
more time to dig on this for now, but here is what I think may be 
happening:


As the OP stated in [1], the close on the GKOP for the statement pool 
calls BaseGOP stopEvictor.  This results in 
EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis, 
TimeUnit.MILLISECONDS) being called with a evictor null.  This starts with


if (evictor != null) {
    evictor.cancel();
}
if (executor != null && executor.getQueue().isEmpty()) {
    executor.shutdown();

}

A quick look at the jdk sources for the executor makes me think it is 
possible that if there is just one other evictor running and it is in 
process of running a task when the test above is performed, the queue 
may show as empty because it has taken the queued task, is executing 
it and only re-queues afterward.  That could cause the main executor 
to be shut down.


To make this happen, it would be best to add some latency to eviction 
tasks and have another one open and close a bunch of others with 
evictors disabled concurrently.  If this turns out to be correct, a 
simple fix would be to just exit immediately if evictor is null (a 
null evictor can't be the last one).


Thinking about this some more, the quick exit above will handle the DBCP 
statement pool case, but the problem could also happen with non-null 
evictors.  So the code probably needs to be modified to live up to the 
commitment in the EvictionTimer class javadoc (that it keeps track of 
its client pools and shuts down only when they have all shut down).


Phil

Phil


[1] 
http://mail-archives.apache.org/mod_mbox/commons-user/202004.mbox/%3CCAD1sBYus4-j4i2Fs6dvzv_p4z0kaiu_8Yz8qUwXxTGAKp1ef1g%40mail.gmail.com%3E



On 7/5/20 6:04 AM, Gary Gregory wrote:

This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.

I am guessing the test might need to be set up differently.

Gary

On Fri, Jul 3, 2020, 14:35 Robert Paschek
wrote:


Hello,

when I'm running mvn clean test on the current master branch, testEvict
always fails with the same error.

[ERROR] Failures:
[ERROR]   TestAbandonedBasicDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]   TestBasicDataSource.testEvict:946 EvictionTimer thread was
destroyed with numIdle=7(expected: less or equal than 5)
[ERROR]   TestBasicManagedDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]
  TestDataSourceXAConnectionFactory>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)

Is there something wrong with my setup? I'm using Maven 3.6.3 with
AdoptOpenJDK 8.0.252.

Thanks for help.

Regards,
Robert

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

[pool] Re: [DBCP] testEvict fails

[Phil Steitz]

On 7/5/20 11:07 AM, Phil Steitz wrote:


The test looks a little off to me.  I am not sure I fully understand 
what it is trying to do, but I suspect that the reason that it fails 
sporadically (I have seen this myself) is that to succeed it needs to 
run two evictor cycles when it is set to wait for only one.  I may be 
wrong as I don't fully follow the intent or logic of the test.


Looks to me like what it is trying to do is:

 1. Create and force initialization of a BDS with initialsize = 10,
minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
 2. Execute a loop whose guard I don't understand that appears to wait
for an eviction cycle to complete, waiting at least 1 second
between iterations
 3. Expect to see no more than 5 idle connections.

I don't understand the search for eviction threads in the guard in 2.  
Just waiting would work if what we are trying to do is to verify that 
old connections are being evicted (basically duplicating tests in 
[pool]).  In any case, in order to get down to 5, you need to run 2 
cycles, because each only visits 3.  It would seem to me that to make 
it succeed consistently, you need to either increase 
numTestsPerEvictionRun to 5 or have it wait for two cycles.


Phil



I think I now understand the intent of the test and I think that what it 
is trying to do points to what may be a [pool] bug.  The post mentioned 
in the PR that created this test [1] may be onto something.


It seems odd that closing a GKOP with no evictor can stop the evictor 
for a different GOP, but I think it may be possible.  I don't have any 
more time to dig on this for now, but here is what I think may be happening:


As the OP stated in [1], the close on the GKOP for the statement pool 
calls BaseGOP stopEvictor.  This results in 
EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis, 
TimeUnit.MILLISECONDS) being called with a evictor null.  This starts with


if (evictor != null) {
    evictor.cancel();
}
if (executor != null && executor.getQueue().isEmpty()) {
    executor.shutdown();

}

A quick look at the jdk sources for the executor makes me think it is 
possible that if there is just one other evictor running and it is in 
process of running a task when the test above is performed, the queue 
may show as empty because it has taken the queued task, is executing it 
and only re-queues afterward.  That could cause the main executor to be 
shut down.


To make this happen, it would be best to add some latency to eviction 
tasks and have another one open and close a bunch of others with 
evictors disabled concurrently.  If this turns out to be correct, a 
simple fix would be to just exit immediately if evictor is null (a null 
evictor can't be the last one).


Phil

Phil


[1] 
http://mail-archives.apache.org/mod_mbox/commons-user/202004.mbox/%3CCAD1sBYus4-j4i2Fs6dvzv_p4z0kaiu_8Yz8qUwXxTGAKp1ef1g%40mail.gmail.com%3E



On 7/5/20 6:04 AM, Gary Gregory wrote:

This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.

I am guessing the test might need to be set up differently.

Gary

On Fri, Jul 3, 2020, 14:35 Robert Paschek
wrote:


Hello,

when I'm running mvn clean test on the current master branch, testEvict
always fails with the same error.

[ERROR] Failures:
[ERROR]   TestAbandonedBasicDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]   TestBasicDataSource.testEvict:946 EvictionTimer thread was
destroyed with numIdle=7(expected: less or equal than 5)
[ERROR]   TestBasicManagedDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]
  TestDataSourceXAConnectionFactory>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)

Is there something wrong with my setup? I'm using Maven 3.6.3 with
AdoptOpenJDK 8.0.252.

Thanks for help.

Regards,
Robert

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

Re: [DBCP] testEvict fails

[Phil Steitz]

The test looks a little off to me.  I am not sure I fully understand 
what it is trying to do, but I suspect that the reason that it fails 
sporadically (I have seen this myself) is that to succeed it needs to 
run two evictor cycles when it is set to wait for only one.  I may be 
wrong as I don't fully follow the intent or logic of the test.


Looks to me like what it is trying to do is:

1. Create and force initialization of a BDS with initialsize = 10,
   minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
   timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
2. Execute a loop whose guard I don't understand that appears to wait
   for an eviction cycle to complete, waiting at least 1 second between
   iterations
3. Expect to see no more than 5 idle connections.

I don't understand the search for eviction threads in the guard in 2.  
Just waiting would work if what we are trying to do is to verify that 
old connections are being evicted (basically duplicating tests in 
[pool]).  In any case, in order to get down to 5, you need to run 2 
cycles, because each only visits 3.  It would seem to me that to make it 
succeed consistently, you need to either increase numTestsPerEvictionRun 
to 5 or have it wait for two cycles.


Phil

On 7/5/20 6:04 AM, Gary Gregory wrote:

This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.

I am guessing the test might need to be set up differently.

Gary

On Fri, Jul 3, 2020, 14:35 Robert Paschek 
wrote:


Hello,

when I'm running mvn clean test on the current master branch, testEvict
always fails with the same error.

[ERROR] Failures:
[ERROR]   TestAbandonedBasicDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]   TestBasicDataSource.testEvict:946 EvictionTimer thread was
destroyed with numIdle=7(expected: less or equal than 5)
[ERROR]   TestBasicManagedDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]
  TestDataSourceXAConnectionFactory>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)

Is there something wrong with my setup? I'm using Maven 3.6.3 with
AdoptOpenJDK 8.0.252.

Thanks for help.

Regards,
Robert

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

Re: [DBCP] poolPreparedStatements

[Phil Steitz]

> On Jun 30, 2020, at 2:36 PM, Gary Gregory  wrote:
> 
> How about clearStatementPoolOnReturn.

+1

Phil
> 
> You do not need to say "Prepared" in the name IMO since we only pool
> prepared statements. The above name actual says what happens when.
> 
> The full version of that name if you want to be extra specific would be
> clearPreparedStatementPoolOnConnectionReturn.
> 
> Gary
> 
>> On Tue, Jun 30, 2020, 16:59 Robert Paschek 
>> wrote:
>> 
>> ​Thanks for the implementation hints. I'm willing to look into this.
>> 
>> Can you think of a better propertyname than
>> limitPreparedStatementPoolToConnectionUse? While the meaning is clear (at
>> least to me), it's also quite long.
>> 
>> Robert
>> 
>> 
>> From: Phil Steitz 
>> Sent: Dienstag, 30. Juni 2020 21:07
>> To: dev@commons.apache.org
>> Subject: Re: [DBCP] poolPreparedStatements
>> 
>> 
>>> On 6/29/20 12:17 PM, Robert Paschek wrote:
>>> Hello,
>>> 
>>> DBCP has a feature to pool PreparedStatements for the lifetime of a
>> connection.
>>> This results in cursors being open and locks in the database for a long
>> time, which could cause problems with administrative tasks in the database.
>> That why I would prefer this pool to be more short-living, that means that
>> the pool is filled while the application  is using the connection und
>> cleared when the application is returning the connection to the
>> ConnectionPool. This way the application can still benefit from the
>> Statement-cache in mass operations, without creating headaches for database
>> admins.
>>> 
>>> I would suggest an additional setting like
>> limitPreparedStatementPoolToConnectionUse or something similar.
>>> 
>>> What do you think?
>>> 
>>> Regards,
>>> Robert
>> 
>> One way to workaround the need to periodically clean up would be to
>> either set maximum lifetimes on connections or periodically invalidate
>> them.  That would force the underlying PoolingConnections to be closed,
>> which would in turn cause the statement pools to be closed.
>> 
>> The feature request sounds reasonable to me.  For anyone interested in
>> creating a patch to implement this, here is a way that might work to
>> implement it:
>> 
>> Connections that pool statements are PoolingConnections.  Add a property
>> to this class to determine whether or not to clear the statement pool
>> when a connection is returned to the pool. Override
>> DelegatingConnnection's passivate method to first call super() but then
>> examine the property and if so configured, clear (not close) the
>> statement pool.  Modify PoolableConnectionFactory to set the property
>> and BasicDataSource to pass it in.
>> 
>> Probably best to open a JIRA for this.  I don't have time to work on it
>> now, but I would be willing to review PRs.
>> 
>> Phil
>> 
>>> 
>> 
>> 

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

Re: [DBCP] poolPreparedStatements

[Phil Steitz]

On 6/29/20 12:17 PM, Robert Paschek wrote:

Hello,

DBCP has a feature to pool PreparedStatements for the lifetime of a connection.
This results in cursors being open and locks in the database for a long time, 
which could cause problems with administrative tasks in the database. That why 
I would prefer this pool to be more short-living, that means that the pool is 
filled while the application is using the connection und cleared when the 
application is returning the connection to the ConnectionPool. This way the 
application can still benefit from the Statement-cache in mass operations, 
without creating headaches for database admins.

I would suggest an additional setting like 
limitPreparedStatementPoolToConnectionUse or something similar.

What do you think?

Regards,
Robert


One way to workaround the need to periodically clean up would be to 
either set maximum lifetimes on connections or periodically invalidate 
them.  That would force the underlying PoolingConnections to be closed, 
which would in turn cause the statement pools to be closed.


The feature request sounds reasonable to me.  For anyone interested in 
creating a patch to implement this, here is a way that might work to 
implement it:


Connections that pool statements are PoolingConnections.  Add a property 
to this class to determine whether or not to clear the statement pool 
when a connection is returned to the pool. Override 
DelegatingConnnection's passivate method to first call super() but then 
examine the property and if so configured, clear (not close) the 
statement pool.  Modify PoolableConnectionFactory to set the property 
and BasicDataSource to pass it in.


Probably best to open a JIRA for this.  I don't have time to work on it 
now, but I would be willing to review PRs.


Phil





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

Re: [VOTE] Release Apache Commons Pool 2.8.0 based on RC1

[Phil Steitz]

+1 (nonbinding)

Checked build, sigs, reviewed changelog, release notes and ran my soak 
tests.  All looks good to me.


Thanks, Gary!

Phil

On 12/10/19 7:57 AM, Gary Gregory wrote:

My +1

Gary

On Sat, Dec 7, 2019 at 6:09 PM Gary Gregory  wrote:


We have fixed a few bugs and provided enhancements since Apache Commons
Pool 2.7.0 was released, so I would like to release Apache Commons Pool
2.8.0.

Apache Commons Pool 2.8.0 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1 (svn
revision 37135)

The Git tag commons-pool-2.8.0-RC1 commit for this RC is
cfb886a6048071fb214fe00861438035f08f288b which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=cfb886a6048071fb214fe00861438035f08f288b
You may checkout this tag using:
 git clone https://gitbox.apache.org/repos/asf/commons-pool.git
--branch commons-pool-2.8.0-RC1 commons-pool-2.8.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1480/org/apache/commons/commons-pool2/2.8.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Dec 07 18:00:34 EST 2019

commons-pool2-2.8.0-bin.tar.gz=9eae6b7e0870542601712ce47f1bdc8aea4c2cdde41ecb1b5593fae3b04530c520229dc73e56c77ba51e99151e7346f5e8ea52a3342605f9c8eb02797abf2c31

commons-pool2-2.8.0-bin.zip=6f055111f53c710cf08c159d3465639f42e455112d198ec931dd900399497b9ce61283ed5cb34c0c915e3001e2c73ab81840ae7aecce51a78f74f47ab0c6ec05

commons-pool2-2.8.0-bin.zip.asc=b8d362085f6b8908672d9576f9efc454ec614c5f1453845b2636650d1542dfd311553aabebff6abd5f3fcaa669f685e379e7bbc9dc88ccc23f9ec0a5ee6d6e00ca30

commons-pool2-2.8.0-sources.jar=63eb36b95fed826d02bddf56b2007db4d932518ba5ed880847c36dea4175a407d6a76d64d6e264cb0f0d6a43e67c4151cd461d5f04bfc6d2aa40224a5e52dd15c156

commons-pool2-2.8.0-src.tar.gz=04fd7c03859c7c017bbce9f3648f09c56248226e0056147bfd672dd1fd07703a9b06925c3bcbf1ae8e48642f46993d4d715083572b06b0d6695af7dcf1fee0cc

commons-pool2-2.8.0-src.zip=ae80fa109c1dfe773dd4d4de55aa2a0eaa02b44edf30fc0da7fae678acb2a5512f14873ab3aed9b37272ad00ba8ac0c015a76c7cac35e6cc015f238ce2edcf84

commons-pool2-2.8.0-test-sources.jar=e8b4ccc429418abae41cd128f2f66bb5acc258fb3a6a8a35616693843773adc0961926af173bc150a51968a2ee064102403c04095b08d6c18eeaaae2d554530a

commons-pool2-2.8.0-tests.jar=4c83fb83c53585fcbab746313aabd1a092111cd13da51e03f99a22b33cc9007d3b1c4b3ba8c449d01ffd2c8f67ad3cd6bceb639c0cb41b3d7e358aec695207dc

commons-pool2-2.8.0.jar.asc=09df2123fb5e2292428eb851b29757afe45d7be1135e2fa25a01d760e730a1616e7eaec1b3cb402b3baceac6f652c8b03e8411b3ff3dacb9b15b3b0b5338

I have tested this with 'mvn -V -Duser.name=%my_apache_id%
-Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
-Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Java\apache-maven-3.6.3\bin\..
Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_231\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 2.7.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1/site/index.html
 (note some *relative* links are broken and the 2.8.0 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.7.0):

https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/pool/2.8.0-RC1/site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-pool.git --branch
commons-pool-2.8.0-RC1 commons-pool-2.8.0-RC1
cd commons-pool-2.8.0-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which you
then must check.

mvn apache-rat:check

3) Check binary compatibility

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page which
you then must check.

mvn install -DskipT

Re: Restoring something like the svn browser

[Phil Steitz]

Thanks!

I was able to see history both ways and found the tags under "releases"

Phil

On 10/11/19 4:49 AM, Emmanuel Bourg wrote:

Le 11/10/2019 à 02:39, Phil Steitz a écrit :

Today I tried to find where a bug reported against what I suspect is
DBCP 1.4 (I think that is likely what tomcat 7 pulls in) was fixed. It
appears to be fixed in the 1.5 branch, but it is impossible now to
actually see history via the browser.

Hi Phil,

You can try these URLs:

https://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/?pathrev=1755453
https://svn.apache.org/viewvc/commons/proper/dbcp/branches/DBCP_1_5_x_BRANCH/?view=log&pathrev=1755453


Alternatively, you could also look at the 1.5 branch on GitHub:

   https://github.com/apache/commons-dbcp/commits/DBCP_1_5_x_BRANCH

Emmanuel Bourg

-
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

Restoring something like the svn browser

[Phil Steitz]

Today I tried to find where a bug reported against what I suspect is 
DBCP 1.4 (I think that is likely what tomcat 7 pulls in) was fixed. It 
appears to be fixed in the 1.5 branch, but it is impossible now to 
actually see history via the browser.  The git browser has a "history" 
link, but clicking it results in a permission error.  The release tags 
for the 1.x releases appear to be gone as well.


The old svn browser is tantalizingly available, but just dead ends to a 
link saying dbcp has moved to git.  Is there any way we can make the svn 
browser available to see the old tags and revision history?


Phil

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