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] > >
