rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1900594023
@cstamas are we talking about testGAVCliReposAndDepsSingleRepo
(https://gist.github.com/rmannibucau/8a68d01504b2ab02ef8aacf6a1e26e65), it is
the only issue I get with the PR (I a
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1900529789
Reproducer: is JBang test on this branch:
https://github.com/jbangdev/jbang/pull/1716
If you use resolver w/o this patch, it consistently ends up with IOEx: too
many streams. With
rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1900525709
@cstamas can you point out the reproducer? The thing is that http2 without
ssl uses a pool whereas it does not over ssl and there the system property is a
similar workaround than
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1900395350
Usually remote reposes have different URLs (usually different hosts), so
yes, a repo is one distinct connection. Usually. I may imagine someone defines
central1, central2, etc and al
rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896498271
> So the workaround is that if you hit this issue with remote repository
"foo", then you can check in .mvn/maven.config that sets proper value for
repository "foo" (check the con
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896389068
> Now about your fix we still have the same issue, you set it to 100 but
then it is set to 12 so maybe we should revert and default to http1?
Hence the "workaround": exposed co
rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896342446
It works cause it is per connection but agree it is bad from a design
standpoint - but it is http2, we cant help.
As a side note my thread count for resolver is always 512
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896309679
Wrong, as if remote server on first response tells client "my
max_concurrent_stream=12" then client will have to obey it AFAIK.
Again, see first paragraph. Yes, instead of Inte
rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896294912
> the fact HttpClient inits this value to Integer.MAX_VALUE and lowers it on
first response
just means each connection much await the first response, a semaphore does
not
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896267693
Ah, so if you mean the system property, that will set it, but will it queue
requests over 100?
--
This is an automated message from the Apache Git Service.
To respond to the messag
cstamas commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896262783
@rmannibucau sorry, we did it at same moment :smile:
Can you provide a PR to show what you mean? Also, the fact HttpClient
_inits_ this value to `Integer.MAX_VALUE` and lowers
cstamas merged PR #408:
URL: https://github.com/apache/maven-resolver/pull/408
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.
rmannibucau commented on PR #408:
URL: https://github.com/apache/maven-resolver/pull/408#issuecomment-1896260133
why not using `jdk.httpclient.maxstreams`? I kind of fail to see how a
semaphore helps, we should just ensure to respect server settings no, so a
"warmup" call then we know and j
cstamas opened a new pull request, #408:
URL: https://github.com/apache/maven-resolver/pull/408
Artificially limit the max concurrent request count doable with
JDK HttpClient, as otherwise you may end up with IOEx.
The value is exposed as config param, so users can tweak it.
Valu
14 matches
Mail list logo
