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]
