[Geoserver-devel] GeoServer/GeoTools PMC Meeting at 17:30 UTC tomorrow

Reminder that the next PMC meeting is scheduled for tomorrow, December 22, at 17:30 UTC.

You can join the meeting via Jitsi: https://meet.jit.si/GeoServerMeeting

Cheers,

Torben Barsballe
Professional Services Engineer
Planet
torben.barsballe@anonymised.com

Hi,

For this meeting I would very much like a discussion on my development of a factory for HTTPClient’s.
https://github.com/geotools/geotools/pull/3256

I haven’t heard anyone complaining about introducing such a factory. The discussion has more been on my approach to create a new project gt-http. After taking a look at the JUnit cases surrounding http clients, I think that it makes sense to bring in a new, easy to find library. But I’m open for any decision.

Another point has been the usage of commons-httpclient. This is an old, unmaintained library that today are used by gt-wms and gt-wfs in their own MultithreadedHttpClients. I was looking a bit on this, but I see no advantage of using it, so I reverted all my changes. There are some bugs related to these two clients, so it would make sense to introduce a new unsupported plugin gt-http-commons with the MultithreadedHttpClient from gt-wms. I’m open for doing this, but maybe in a new PR when this is done.

What I do want to work on is the new HttpClient in JDK 11. My initial plan has been to introduce a new plugin gt-http-ng, but that will be introduced in a new Jira / PR.

The timing of this meeting isn’t very practical for me, so I’m afraid I can’t attain, but I’m open for any input whether it’s at the maillist, JIRA or Github.

Regards,

Roar Brænden

  1. des. 2020 kl. 18:44 skrev Torben Barsballe <torbenbarsballe@anonymised.com>:

Reminder that the next PMC meeting is scheduled for tomorrow, December 22, at 17:30 UTC.

You can join the meeting via Jitsi: https://meet.jit.si/GeoServerMeeting

Cheers,

Torben Barsballe
Professional Services Engineer
Planet
torben.barsballe@anonymised.com


GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
geotools-devel List Signup and Options

Another point has been the usage of commons-httpclient. This is an old, unmaintained library that today are used by gt-wms and gt-wfs in their own MultithreadedHttpClients. I was looking a bit on this, but I see no advantage of using it, so I reverted all my changes.

No advantage compared to the Java 8 client? Performs better as far as I know. I always have it on in GeoServer deploys, leaving the Java 8 client for
cases where

There are some bugs related to these two clients, so it would make sense to introduce a new unsupported plugin gt-http-commons with the MultithreadedHttpClient from gt-wms. I’m open for doing this, but maybe in a new PR when this is done.

Having a module for it would make sense indeed.

What I do want to work on is the new HttpClient in JDK 11. My initial plan has been to introduce a new plugin gt-http-ng, but that will be introduced in a new Jira / PR.

For this to work, we need to discuss switching to JDK 11 as the minimum supported version (release packages are built with Java 8, Java 11 is in the builds
to make sure projects work with it, though we have issues with modularity as no one of core devs is really using it).

Normally the discussion open when the next LTS is released, which will be Java 17 in September 2021… historically, we do a code sprint a few months later to

add support for the new LTS and drop the old one (so the switch would be from Java 8 and Java 11, to Java 11 and Java 17).
At the same time, Java 8 is supported until 2026, and Java 11 only up to 2024*, which is not ideal, a switch would actually reduce the time the servers deploying
those versions can stay up without an overhaul.

Cheers
Andrea

*: https://adoptopenjdk.net/support.html

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

  1. des. 2020 kl. 11:23 skrev Andrea Aime <andrea.aime@anonymised.com>:

On Tue, Dec 22, 2020 at 9:05 AM Roar Brænden <roar.brenden.no@anonymised.com> wrote:

Another point has been the usage of commons-httpclient. This is an old, unmaintained library that today are used by gt-wms and gt-wfs in their own MultithreadedHttpClients. I was looking a bit on this, but I see no advantage of using it, so I reverted all my changes.

No advantage compared to the Java 8 client? Performs better as far as I know. I always have it on in GeoServer deploys, leaving the Java 8 client for
cases where

My assumption was based on a little test case. If you have experienced something else, I wan’t argue with that.

There are some bugs related to these two clients, so it would make sense to introduce a new unsupported plugin gt-http-commons with the MultithreadedHttpClient from gt-wms. I’m open for doing this, but maybe in a new PR when this is done.

Having a module for it would make sense indeed.

I will incorporate it in the PR. Which is having trouble with the Github checks.

What I do want to work on is the new HttpClient in JDK 11. My initial plan has been to introduce a new plugin gt-http-ng, but that will be introduced in a new Jira / PR.

For this to work, we need to discuss switching to JDK 11 as the minimum supported version (release packages are built with Java 8, Java 11 is in the builds
to make sure projects work with it, though we have issues with modularity as no one of core devs is really using it).

Normally the discussion open when the next LTS is released, which will be Java 17 in September 2021… historically, we do a code sprint a few months later to

add support for the new LTS and drop the old one (so the switch would be from Java 8 and Java 11, to Java 11 and Java 17).
At the same time, Java 8 is supported until 2026, and Java 11 only up to 2024*, which is not ideal, a switch would actually reduce the time the servers deploying
those versions can stay up without an overhaul.

Would it make sense to make a plugin with a HTTPClient based on Apache HttpComponents then?

Regards,

Roar Brænden

Sure, I’d love to see that personally. We’ll have the meeting in half an hour and discuss this and the other points

Cheers
Andrea

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.