Re: [CRYPTO] Drop support for OpenSSL < 1.1 ?

2023-11-09 Thread Gary Gregory 
Maybe post this on the user's ML just in case?

Gary

On Wed, Nov 8, 2023, 8:13 PM Alex Remily  wrote:

> +1
>
> On Wed, Nov 8, 2023, 7:24 PM sebb  wrote:
>
> > I would really like to drop support for the oldest versions of SSL, i.e.
> > 1.0.x
> > These are seriously out of date.
> > Can we even test them properly?
> >
> > Unless I hear otherwise, I propose to remove the code next week.
> >
> > Sebb
> > On Mon, 30 Oct 2023 at 14:33, sebb  wrote:
> > >
> > > On Mon, 30 Oct 2023 at 12:31, Gary Gregory 
> > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I am OK with dropping support for versions below 1.1.1 but it does
> not
> > > > seem crucial.
> > > >
> > > > I would prefer we do a release for this before we do anything more
> > toward 3.x.
> > >
> > > Not sure I understand what you mean here.
> > >
> > > Do you mean we should do a release purely to drop support for versions
> > > below 1.1?
> > > Or something else?
> > >
> > > Note I am not suggesting dropping support for 1.1.0 yet, but for
> > > versions before that, i.e. 1.0.x.
> > >
> > > > Gary
> > > >
> > > > On Sun, Oct 29, 2023 at 8:49 PM Alex Remily 
> > wrote:
> > > > >
> > > > > Good question.  I've asked it myself.  I've been planning on doing
> an
> > > > > upgrade to support OpenSSL 3.X.+ that maintains support for 1.1.X.
> > That
> > > > > said, it's been at least a year and I haven't gotten around to it,
> > and I'm
> > > > > not firmly committed to the idea of maintaining backwards
> > compatibility.  I
> > > > > think that if we're going to break backwards compatibility with
> older
> > > > > versions, the upgrade to 3.X would probably be a good time to do
> > it.  From
> > > > > what little I've read on the subject, the move from 1.1.1 to 3.X
> is a
> > > > > significant change.  In short, I would be in favor of dropping
> legacy
> > > > > OpenSSL support in the next commons crypto release.
> > > > >
> > > > > Alex
> > > > >
> > > > > On Sun, Oct 29, 2023 at 9:15 AM sebb  wrote:
> > > > >
> > > > > > There is quite a lot of Crypto code that depends on the check:
> > > > > >
> > > > > > if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
> > > > > > where
> > > > > > VERSION_1_1_X = 0x1010;
> > > > > >
> > > > > > Dropping such support would simplify the code.
> > > > > >
> > > > > > Is there any need to continue to support such old versions?
> > > > > >
> > > > > > 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
> >
> >
>

Re: [CRYPTO] Drop support for OpenSSL < 1.1 ?

2023-11-09 Thread sebb 
We don't do that before bumping the minimum Java version ...

On Thu, 9 Nov 2023 at 10:26, Gary Gregory  wrote:
>
> Maybe post this on the user's ML just in case?
>
> Gary
>
> On Wed, Nov 8, 2023, 8:13 PM Alex Remily  wrote:
>
> > +1
> >
> > On Wed, Nov 8, 2023, 7:24 PM sebb  wrote:
> >
> > > I would really like to drop support for the oldest versions of SSL, i.e.
> > > 1.0.x
> > > These are seriously out of date.
> > > Can we even test them properly?
> > >
> > > Unless I hear otherwise, I propose to remove the code next week.
> > >
> > > Sebb
> > > On Mon, 30 Oct 2023 at 14:33, sebb  wrote:
> > > >
> > > > On Mon, 30 Oct 2023 at 12:31, Gary Gregory 
> > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I am OK with dropping support for versions below 1.1.1 but it does
> > not
> > > > > seem crucial.
> > > > >
> > > > > I would prefer we do a release for this before we do anything more
> > > toward 3.x.
> > > >
> > > > Not sure I understand what you mean here.
> > > >
> > > > Do you mean we should do a release purely to drop support for versions
> > > > below 1.1?
> > > > Or something else?
> > > >
> > > > Note I am not suggesting dropping support for 1.1.0 yet, but for
> > > > versions before that, i.e. 1.0.x.
> > > >
> > > > > Gary
> > > > >
> > > > > On Sun, Oct 29, 2023 at 8:49 PM Alex Remily 
> > > wrote:
> > > > > >
> > > > > > Good question.  I've asked it myself.  I've been planning on doing
> > an
> > > > > > upgrade to support OpenSSL 3.X.+ that maintains support for 1.1.X.
> > > That
> > > > > > said, it's been at least a year and I haven't gotten around to it,
> > > and I'm
> > > > > > not firmly committed to the idea of maintaining backwards
> > > compatibility.  I
> > > > > > think that if we're going to break backwards compatibility with
> > older
> > > > > > versions, the upgrade to 3.X would probably be a good time to do
> > > it.  From
> > > > > > what little I've read on the subject, the move from 1.1.1 to 3.X
> > is a
> > > > > > significant change.  In short, I would be in favor of dropping
> > legacy
> > > > > > OpenSSL support in the next commons crypto release.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Sun, Oct 29, 2023 at 9:15 AM sebb  wrote:
> > > > > >
> > > > > > > There is quite a lot of Crypto code that depends on the check:
> > > > > > >
> > > > > > > if (dlsym_OpenSSL_version_num() < VERSION_1_1_X)
> > > > > > > where
> > > > > > > VERSION_1_1_X = 0x1010;
> > > > > > >
> > > > > > > Dropping such support would simplify the code.
> > > > > > >
> > > > > > > Is there any need to continue to support such old versions?
> > > > > > >
> > > > > > > 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: Multi Tenant Connection Pool

2023-11-09 Thread Jesse Harris 
The downside of a map of pools is that it is not as dynamic as a design
that just "prefers" affinity with an arbitrary key. The map of pools works
well when you are connection rich and tenant poor, however when you have a
scenario where you may be facing 2x tenants to db connections with
sparse usage across tenants in bursts, you end up having to create a lot of
new connections. The per user datasource would accomplish that wouldn't it,
of course it requires more sql user creation, configuration and whatnot to
go along with that.

Also this would require knowing all of the configuration at startup time,
new tenants should be able to be added without restart and just dynamically
route properly and minimize the USE statements, what I am seeking is a much
more dynamic solution, something where connections are routed (with a USE
statement) only when necessary, and selection from the pool would just
favor the ones with affinity.

I know it sounds simple and of course the devil is in the details, but I
have yet to be able to explain why that would not work.

thanks!
-jesse

On Wed, Nov 8, 2023 at 11:36 PM Romain Manni-Bucau 
wrote:

> Hi jessie,
>
> Think it can makes sense but not sure it fits in commons-dbcp "core" since
> the best is generally to not merge the connection in the same pool but use
> N pools and enable the database to inject a custom "router"/selector
> (that's what spring or tomee did for ex [1]/[2]).
> The rational to do it like that is to leverage autosizing and
> optimizations.
> Indeed you can add a map on top of the pool in the pool but I'm not sure
> the benefit so it should mainly be importing the facade and router api and
> facade existing pools (which must all keep a distinct configuration,
> customer1=size=200, customer2=size=10 for ex, this is where keeping N
> pooled datasources is way easier than merging it in a single instance ->
> getCurrentDataSource() ;)).
>
> Side note: if used with JPA it must NOT be used with JPA cache nor used for
> transversal things like app-pool+customer-pool in the same transaction AND
> it will make XA usage delegated to the underlying datasource if needed and
> not to the pool directly.
>
> So my 2cts would be to create a new package (dynamic or whatever name you
> like) and import the facade and create the selecting api and be it, will
> also fit when the database is distinct, schema or just the sizing is
> different per customer to avoid side effects of one customer on another one
> on reactive apps.
>
> Hope it makes sense.
>
> [1]
>
> https://github.com/apache/tomee/blob/bc8f54e3f5b1674b3f6ced4bd564a1c48c32c5bc/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/RoutedDataSource.java
> [2]
>
> https://github.com/spring-projects/spring-framework/blob/main/spring-jdbc/src/main/java/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.java
>
> Best,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 9 nov. 2023 à 00:39, Gary Gregory  a
> écrit :
>
> > Hi Jesse,
> >
> > Please take a look at Commons DBCP and how your proposal would fit in.
> >
> > Gary
> >
> > On Wed, Nov 8, 2023, 4:49 PM Jesse Harris  .invalid>
> > wrote:
> >
> > > Would there be any interest in contributing an implementation of a
> multi
> > > tenant connection pool implementation?
> > >
> > > One implementation of a multi-tenant architecture is to have a schema
> per
> > > tenant, the downside is that you need to set the default database on
> each
> > > connection pulled from the pool, this creates a lot of overhead.
> Ideally
> > a
> > > pool with "affinity" based on an arbitrary key, pull a connection
> already
> > > prepared for the given schema, if there is not one, steal one from
> > another
> > > schema and reset the default schema in that case.
> > >
> > > The problem with the per-user pool is that it requires a per schema
> user,
> > > also when stealing connections you have to recreate the socket when the
> > > user changes.
> > >
> > > thanks in advance
> > > -jesse
> > >
> >
>

[COMMONS COMPRESS] COMPRESS-650 - lz4 compress throws IndexOutOfBoundsException

2023-11-09 Thread Chad Preisler 
Hello,

I've created JIRA COMPRESS-650 for a bug I found while doing lz4
compression. I also created a pull request with a fix for this bug. Please
let me know what you think.

https://github.com/apache/commons-compress/pull/436

Thanks,
Chad Preisler