Am 2019-11-26 um 20:51 schrieb Oleg Kalnichevski:
On Tue, 2019-11-26 at 20:31 +0100, Michael Osipov wrote:
Am 2019-11-26 um 20:13 schrieb Oleg Kalnichevski:
On Tue, 2019-11-26 at 19:08 +0100, Michael Osipov wrote:
Am 2019-11-26 um 16:41 schrieb Oleg Kalnichevski:
Folks

I would like to create new 4.5.x branch in HttpCore and do the
following

* change its version to 4.5.0-alpha1

* change its JRE level from 1.6 to 1.7

* back-port new connection pool implementations from master to
that
branch

* deprecate old connection pool implementations

Would anyone have any objections to that?

Obviously all new features would need to the 4.5.x branch and
not
4.4.x. The 4.4.x would be for critical bug fixes only.

I don't understand why you want to do that? Do you want to evolve
the
4.x branch in parallel to master like Tomcat does? I thought 5.0
is
a
successor to the 4.x line.


Realistically we cannot deprecate and stop supporting the 4.x code
line
the same moment 5.0 goes GA. We will have to support both 4.x and
5.x
for quite some time.

Yes, I see. That makes sense. We should also agree how long the 4.x
is
going to be supported and how the support will look like. Fixes only,
or
backports too.

Recently the old connection pooling code in HttpAsyncClient has
been
giving me quite some grief. Ideally I would like to be able to
replace
it with something known to be better instead of having to patch the
old
implementation all the time.

Is Commons Pool an option? Or even the high-performance Tomcat JDBC
Pool
stripped for the JDBC part? It is little code compared to Commons
Pool.


It is an option but what would exactly be the upside? On the downside
we would likely lose the ability to support stateful connections that
we presently have in 4.x and 5.x.

Upside: we use well tested, existing ASF code.

Can you describe why we would lose stateful connections? Database connections are stateful too.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to