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]
