btw be careful with jdk httpclient as it doesn't really a way to cleanup resources (see https://bugs.openjdk.org/browse/JDK-8304165) could be an issue with mvnd
On Fri, 13 Oct 2023 at 19:20, Christoph Läubrich <[email protected]> wrote: > > You can find JDK http client debugging / configuration options here: > > https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html > > sadly they seem not configurable per cbut only globally but probably > someone like to suggest this to the JDK team (e.g. something like > builder.setProperty(...) ) > > > Am 13.10.23 um 10:28 schrieb Michael Osipov: > > I agree that this is a full rewrite, sadly. > > > > Have you evaluated what degree of logging both JEtty Client and the JDK > > Client offer? I consider the JDK client likely as useless in this regard. > > Don't know about Jetty. At least AHC saved me a lot of trouble... > > > > On 2023/10/13 08:23:33 Tamás Cservenák wrote: > >> And just add more context about transports: > >> > >> Currently we have Wagon and AHC 4.x ("native") transport in Maven (since > >> 3.9). Numbers show that "native" is far superior over Wagon (I think we can > >> all agree on this). > >> > >> Sadly, "native" relies on EOL (or soon EOL?) library AHC 4.x (that is one > >> of the best HTTP libraries I used), and this implies we are stuck with > >> HTTP/1.1 only and (probably, hopefully?) bugfix releases only. Ironically, > >> the moment we provided "superior" HTTP transport in Maven, we got stuck at > >> the same time. While there is AHC 5.x (sync, that is not HTTP/2 capable, > >> and async, both require heavy rewrite), switching to it requires _full > >> rewrite_ as mentioned. Plus the "go async" if you want to leverage any new > >> protocol. Basically it is like writing resolver transport from scratch. > >> > >> Hence, I think it is more sane to invest our effort into something more > >> stable, that at the same time gives us (promises us) future headroom as > >> well, and IMHO JDK/JRE net.http.HttpClient and (in my experience) Jetty > >> HttpClient are such things. There is no need for _full rewrite_ between > >> major versions. > >> > >> In the longer term, this will actually lower the needed effort to maintain > >> these resolver transports, while at the same time prevent us being cornered > >> again. > >> > >> On Fri, Oct 13, 2023 at 10:11 AM Tamás Cservenák <[email protected]> > >> wrote: > >> > >>> Howdy, > >>> > >>> Re perf (and this was already discussed about a year ago, please do not > >>> derail discussion): look around > >>> https://github.com/apache/maven-resolver/pull/231 and related JIRAs, > >>> there are the numbers. TL;DR: jetty and jdk clients are consistently > >>> fastest and are "side by side" (with the benefit of Jetty doing HTTP/3 as > >>> well, but with the downside of huge dep trail), while Wagon is > >>> consistently > >>> the slowest. Differences wildly differ but are very notable. > >>> > >>> Personally, I am not interested in doing a full rewrite of existing AHC > >>> transport (as the expected amount of bugs doing this is pretty much on par > >>> with doing fully new transport from scratch). I'd rather just choose a > >>> library with a more stable API, like Jetty is. Moreover, forcing "async" > >>> style in 2023 is something I'd avoid in today's written Java code (esp > >>> with > >>> 21 virtual threads). But sure, if you want to do it, go for it (this work > >>> would at least move Maven as a project forward, not backward). > >>> > >>> On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov <[email protected]> > >>> wrote: > >>> > >>>> Regardless of the names, the following questions code to my mind: > >>>> > >>>> * Does it make sense to put effort into too many clients? > >>>> * How many users will actually switch the client? I bet < 10% > >>>> > >>>> olegk@ and me assessed many times on JIRA that HTTP/2 will have little > >>>> performance benefit for our use case of transport. I'd like to see a move > >>>> to Apache HttpClient 5 Async which does everything, but that is work. > >>>> Having both AHC async and Jetty HTTP Client is a logical overlap and > >>>> unnecessary maintenance burden. While I know nothing about the Jetty > >>>> Client, the AHC (any version) has exceptional logging output down to > >>>> bytes > >>>> of streams which helps very often to analyze problem with users. > >>>> > >>>> I personally refuse and close out issue on JIRA where the user is not > >>>> able to present that kind of debugging information. Poking in the dark. > >>>> > >>>> M > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
