Less is better in terms of stack so jre client is the way forward for me, it is fast, reliable and keeps getting enhancements.
On http2/3 I dont see it very relevant cause it still gets a lot of issues and should be blacklisted for a while until serious mitigations are set up on servers. In terms of style, virtual threads are just a default async style which is not mainstream and will not for years. It also foes not prevent locking, in particular with our current codebase so a full rewrite is relevant if there is any will and if not becoming lighter is what is the most relevant. All that to say that staying on jre client, keeping an abstractio is what I see as relevant. Other impl can be extensions in an extra repo but sound additional maintenance without end user gain from my window. Le ven. 13 oct. 2023 à 10:30, Michael Osipov <[email protected]> a écrit : > 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] > >
