rschmitt opened a new pull request, #702:
URL: https://github.com/apache/httpcomponents-client/pull/702
See https://github.com/apache/httpcomponents-core/pull/544
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
rschmitt opened a new pull request, #544:
URL: https://github.com/apache/httpcomponents-core/pull/544
It turns out that keep-alive options are supported on all modern
combinations of Java runtimes and operating systems, with the sole excpetion of
Java 8 on Windows. The keep-alive options ar
lethinker commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3166391150
> @lethinker
https://github.com/apache/httpcomponents-client/blob/master/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/extension/async/StandardTestClientBu
rschmitt commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3166384261
@lethinker
https://github.com/apache/httpcomponents-client/blob/master/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/extension/async/StandardTestClientBuild
lethinker commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3166241851
> > It seems that the effected ResponseTimeout is being rounded up to the
nearest second, and milliseconds are not taking effect.
>
> @lethinker Socket timeout granul
ok2c commented on code in PR #543:
URL:
https://github.com/apache/httpcomponents-core/pull/543#discussion_r2261478046
##
httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java:
##
@@ -277,13 +278,14 @@ public final void onInput(final ByteBuff
rschmitt commented on code in PR #543:
URL:
https://github.com/apache/httpcomponents-core/pull/543#discussion_r2261231341
##
httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java:
##
@@ -277,13 +278,14 @@ public final void onInput(final Byte
I learned something very important, which explains why I'm seeing a lot of
reports of TCP resets specifically:
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#connection-idle-timeout
For each TCP request that a client makes through a Network Load Balanc
rschmitt merged PR #542:
URL: https://github.com/apache/httpcomponents-core/pull/542
--
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: dev-unsubscr...@hc.
rschmitt commented on code in PR #542:
URL:
https://github.com/apache/httpcomponents-core/pull/542#discussion_r2260863147
##
httpcore5/src/main/java/org/apache/hc/core5/io/SocketSupport.java:
##
@@ -36,8 +36,11 @@
/**
* @since 5.3
+ *
+ * @deprecated No longer necessary, d
arturobernalg merged PR #700:
URL: https://github.com/apache/httpcomponents-client/pull/700
--
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: dev-unsubscr
What I'd like to know is:
1. Can we do anything to improve this race condition?
Please try this change-set:
https://github.com/apache/httpcomponents-core/pull/543
I should reduce the window of this race condition somewhat.
Oleg
ok2c opened a new pull request, #543:
URL: https://github.com/apache/httpcomponents-core/pull/543
@rschmitt This should reduce the window of the stale connection lease race
condition somewhat.
--
This is an automated message from the Apache Git Service.
To respond to the message, please
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012608#comment-18012608
]
ASF subversion and git services commented on HTTPCLIENT-2384:
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012607#comment-18012607
]
ASF subversion and git services commented on HTTPCLIENT-1822:
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012606#comment-18012606
]
ASF subversion and git services commented on HTTPCLIENT-2385:
rschmitt merged PR #701:
URL: https://github.com/apache/httpcomponents-client/pull/701
--
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: dev-unsubscr...@h
ok2c commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3164323292
> It seems that the effected ResponseTimeout is being rounded up to the
nearest second, and milliseconds are not taking effect.
@lethinker Socket timeout granularity of a
lethinker commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3164276512
> @ok2c @rschmitt can you help me with the problem when I use the
httpAsyncClient( httpclient 5.4.3 、jdk 21) First, I set a 100-second sleep on
the server side to ensure th
lethinker commented on PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#issuecomment-3164182716
@ok2c @rschmitt can you help me with the problem when I use the
httpAsyncClient( httpclient 5.4.3 、jdk 21)
First, I set a 100-second sleep on the server side to ensure t
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012502#comment-18012502
]
ASF subversion and git services commented on HTTPCLIENT-2386:
On 2025-08-06 04:29, Ryan Schmitt wrote:
Since rolling out 5.5 (which includes my change for
`validateAfterInactivity`, which was previously interpreted as a connection
TTL for async HTTP 1.1 connections), I've been getting reports of
intermittent request failures which appear to be caused by
ok2c commented on PR #699:
URL:
https://github.com/apache/httpcomponents-client/pull/699#issuecomment-3163033158
> Where is the original soTimeout restored after the handshake is completed?
@rschmitt Good catch. Please do another pass.
--
This is an automated message from the Apach
ok2c commented on code in PR #542:
URL:
https://github.com/apache/httpcomponents-core/pull/542#discussion_r2259386248
##
httpcore5/src/test/java/org/apache/hc/core5/io/TestSocketSupport.java:
##
@@ -38,6 +38,7 @@
import org.junit.jupiter.api.Assertions;
import org.junit.jupit
ok2c commented on code in PR #542:
URL:
https://github.com/apache/httpcomponents-core/pull/542#discussion_r2259384299
##
httpcore5/src/main/java/org/apache/hc/core5/io/SocketSupport.java:
##
@@ -36,8 +36,11 @@
/**
* @since 5.3
+ *
+ * @deprecated No longer necessary, due t
ok2c commented on code in PR #694:
URL:
https://github.com/apache/httpcomponents-client/pull/694#discussion_r2259331530
##
httpclient5/src/main/java/org/apache/hc/client5/http/impl/nio/DefaultAsyncClientConnectionOperator.java:
##
@@ -165,7 +165,13 @@ public void completed(fina
26 matches
Mail list logo
