Re: HTTP/2 client and closed connections

On 18/03/2024 03:01, Jonathan Amir wrote: Thank you again for your detailed answer. I am wondering about the pros and cons of validateAfterInactivity vs. evictIdleConnections. validateAfterInactivity - I am guessing, for lack of any other information, that inactivity here is meant to be the

Re: HTTP/2 client and closed connections

anism in place but it applies > to idempotent methods only. Please take a look at > DefaultHttpRequestRetryStrategy. HttpClient should automatically re-try > idempotent methods, but non-idempotent method recovery is application > specific and is considered a responsibility of the caller. > > Connec

Re: Connection estabilishment metrics

On Sat, 2024-03-16 at 16:19 +0100, Richard Tippl wrote: > Thanks for your email, I do have a few follow up points. > > I see no way to use a custom HttpClientConnectionOperator with > the PoolingHttpClientConnectionManager, > the manager itself and the Builder seem to always make an instance of >

Re: Connection estabilishment metrics

Thanks for your email, I do have a few follow up points. I see no way to use a custom HttpClientConnectionOperator with the PoolingHttpClientConnectionManager, the manager itself and the Builder seem to always make an instance of the Default with no way of choosing my own. I'm guessing this is

Re: Connection estabilishment metrics

On Fri, 2024-03-15 at 21:56 +0100, Richard Tippl wrote: > ... > There are 2 issues with this approach, as far as i can tell, I can't > measure these times separately, and in the newest alpha version of > 5.4 the > interface I'm using has been deprecated and replaced by the >

Re: Connection estabilishment metrics

The interesting part of my case is that the connection timeout is set to 5 seconds, and while it times out sometimes, the above-mentioned metrics I've already created reveal that some connections start taking 1-3 seconds to actually fully establish. This would indicate some low level

Re: Connection estabilishment metrics

I do have a thought - sometimes its just important to make it work, not to drill into perfectly what it is - I have had some luck with the Resilience4J library, where I set it up on a short timeout - connections that work work within, say, 30ms - and if they take more than 50ms, they're never

Re: HTTP/2 client and closed connections

to idempotent methods only. Please take a look at DefaultHttpRequestRetryStrategy. HttpClient should automatically re-try idempotent methods, but non-idempotent method recovery is application specific and is considered a responsibility of the caller. ConnectionClosedException is presently

Re: HTTP/2 client and closed connections

ectionClosedException. > > > > My initial question is, since there is only one connection maintained > > internally, how does one recover from ConnectionClosedException? The > > connection life-cycle is opaque to me - there is no pool, and no > > eviction > > strategy, so no conc

Re: HTTP/2 client and closed connections

ing? Is > the httpClient object still usable after a ConnectionClosedException? > The internal connection pool can automatically re-establish closed connection once the connection termination handshake completes or the connection gets dropped abnormally. > Somewhat related, I am looking

Re: Websocket client using ReactiveResponseConsumer and ReactiveEntityProducer

On Tue, 2024-03-12 at 10:32 -0400, Sneha Murganoor wrote: > Hi, > > I am writing a websocket client with APIs ReactiveResponseConsumer > and > ReactiveEntityProducer. Once the websocket server completes the > handshake > by upgrading connection and returning 101. We do get Http status code > and

Re: ErrorStream already closed reading response.getBody using FutureRequestExecutionService

On Mon, 2024-02-26 at 14:45 +0100, Volker Hochstein wrote: > Hi, > > I am triggering two http requests in parallel using > FutureRequestExecutionService. > I am trying to read response body in Callback completed: > EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8) > However, I

Re: Missing settings for HttpClient timeouts ?

On 22/02/2024 13:16, Óscar Frías Barranco wrote: Thanks for your reply. I have activated HttpClient logs and it looks like, at least in this case, time is spent in DNS resolution. Is there a way to set a timeout for this (at the HttpClient level if that's possible, or at the OS level

Re: Missing settings for HttpClient timeouts ?

Thanks for your reply. I have activated HttpClient logs and it looks like, at least in this case, time is spent in DNS resolution. Is there a way to set a timeout for this (at the HttpClient level if that's possible, or at the OS level otherwise) ? Feb 22, 2024 1:10:24 PM

Re: Missing settings for HttpClient timeouts ?

On 22/02/2024 11:53, Óscar Frías Barranco wrote: Hello. I am trying to configure HttpClient to validate a list of URLs and I don't want it to take longer than 10 seconds for each URL. I have been searching for all available timeout settings in HttpClient but, even after setting them all to 2

Re: How to Send a Post Request with Plaintext Password without Retaining the Password in Memory

On Tue, 2024-02-13 at 09:52 +, Theodore Tan wrote: > Hello, >   > I’m using HttpClient 5.2.1 for my application, specifically the > HttpPost object to send a POST request and authenticate to an > OAuth2.0 server using grant_type=password. > Since grant_type=password requires a plaintext

Re: Authentication headers are not dropped on redirects

On Mon, 2023-11-27 at 18:32 +, Maksim Chernyshenko wrote: > Good day, everyone! > > Me and my team are in the process of migration to httpclient v5.2 > from v4.5 and we are currently hindered by the following issue: > httpclient5 is not dropping Authentication headers when following >

Re: DefaultCacheInvalidator Mistake

On 14/11/2023 10:28, Naber, Peter wrote: Hi, I get this WARN Message by using the org.apache.hc.client5.http.impl.cache.DefaultCacheInvalidator 14 Nov. 2023 09:17:06.445- DefaultCacheInvalidator [ips2edition-pages-article] WARN org.apache.hc.client5.http.impl.cache.DefaultCacheInvalidator

Re: Fluent API: Retries for specific HTTP status codes

On 13/11/2023 10:06, Konrad Windszus wrote: On 13. Nov 2023, at 09:43, Oleg Kalnichevski wrote: The response body processing takes place outside the protocol handling chain and there is nothing we can do about it. IIRC this isn’t the case with

Re: Fluent API: Retries for specific HTTP status codes

> On 13. Nov 2023, at 09:43, Oleg Kalnichevski wrote: > > The response body processing takes place outside the protocol handling chain > and there is nothing we can do about it. IIRC this isn’t the case with

Re: Fluent API: Retries for specific HTTP status codes

On 10/11/2023 15:31, Konrad Windszus wrote: HI, I am using the Fluent API with HttpClient 4.5 like this: Executor.newInstance(myClient).execute(myRequest).handleResponse(myResponseHandler) [1] Although “myClient" is setup with the default HttpRequestRetryHandler this isn’t triggered when

Re: RevalidateCacheEntry merges headers from cache which do not exist any more

On 08/11/2023 23:50, Sneha Murganoor wrote: I misinterpreted the HTTP protocol. In this case, the server's decision to return a 304 status code was incorrect because there was a change in the metadata, even though there was no change in the payload. Just to clarify, does this mean that when

Re: RevalidateCacheEntry merges headers from cache which do not exist any more

I misinterpreted the HTTP protocol. In this case, the server's decision to return a 304 status code was incorrect because there was a change in the metadata, even though there was no change in the payload. Just to clarify, does this mean that when there is a change in either the payload or

Re: RevalidateCacheEntry merges headers from cache which do not exist any more

On 08/11/2023 15:58, Sneha Murganoor wrote: Thanks for the reply. Yes we understand that when an entry in cache is stale, we make conditional get requests. We are wondering if there is way we dont make conditional get instead just make unconditional get call, since AWS S3 returns as 304 status

Re: RevalidateCacheEntry merges headers from cache which do not exist any more

Thanks for the reply. Yes we understand that when an entry in cache is stale, we make conditional get requests. We are wondering if there is way we dont make conditional get instead just make unconditional get call, since AWS S3 returns as 304 status code even when there is header removed from the

Re: RevalidateCacheEntry merges headers from cache which do not exist any more

On 07/11/2023 17:27, Sneha Murganoor wrote: Use case: We have Caching Apache Http Client calling s3 backend. When metadata (http headers) changes with no changes in payload, s3 sends us "304 NOT Modified" status code with current modified headers. But apache reading 304 merges previous headers

Re: protocol problem in MultiPartAsyncEntityProducer implementation

If I try this code:  final CloseableHttpAsyncClient client = HttpAsyncClients.custom()                .setVersionPolicy(HttpVersionPolicy.FORCE_HTTP_1)                .build();         client.start();             final HttpPost method = new HttpPost("http://localhost:8884;);                   

Re: protocol problem in MultiPartAsyncEntityProducer implementation

On 19/10/2023 13:30, vostinar laurian wrote: Hi, I implemented a MultiPartAsyncEntityProducer, my code is: here | | | servoy-extensions/com.servoy.extensions... | My code is based on FileEntityProducer , just that instead of writing just a file content, it writes more stuff. It seems

Re: Question about usage with Server-Sent events

On Tue, 2023-09-19 at 22:17 +0200, Oleg Kalnichevski wrote: > On Tue, 2023-09-19 at 18:31 +0200, Damien Urruty wrote: > > Hello, > > > > We are using Apache HttpClient 5.2.1 to connect to potentially > > different > > servers, and for each of them, we can have a mix of "classic" HTTP > > requests

Re: Question about usage with Server-Sent events

On Tue, 2023-09-19 at 18:31 +0200, Damien Urruty wrote: > Hello, > > We are using Apache HttpClient 5.2.1 to connect to potentially > different > servers, and for each of them, we can have a mix of "classic" HTTP > requests > and long connections to receive Server-Sent Events. In some cases, we >

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On 2023/09/12 16:29:04 Torsten Krah wrote: > Am Dienstag, dem 12.09.2023 um 18:08 +0200 schrieb Oleg Kalnichevski: > > This statement is meaningless. All versions of HttpClient have their > > own http classes. And all versions of HttpClient have always been > > using > > JSSE for its transport

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

Am Dienstag, dem 12.09.2023 um 18:08 +0200 schrieb Oleg Kalnichevski: > This statement is meaningless. All versions of HttpClient have their > own http classes. And all versions of HttpClient have always been > using > JSSE for its transport security and nothing else. If you are not > happy > with

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On Tue, 2023-09-12 at 18:00 +0200, Torsten Krah wrote: > Am Dienstag, dem 12.09.2023 um 17:54 +0200 schrieb Oleg Kalnichevski: > > Confirms how? HttpClient has always been using JSSE APIs and > > nothing > > else. Like it does now. > > I said the old HttpComponents had their own http classes 

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

Am Dienstag, dem 12.09.2023 um 17:54 +0200 schrieb Oleg Kalnichevski: > Confirms how? HttpClient has always been using JSSE APIs and nothing > else. Like it does now. I said the old HttpComponents had their own http classes and if you look at the code of HttpConnection, it does not extend / use

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On Tue, 2023-09-12 at 17:51 +0200, Torsten Krah wrote: > Am Dienstag, dem 12.09.2023 um 17:42 +0200 schrieb Oleg Kalnichevski: > > http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java?revision=1422573=markup > > >

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

Am Dienstag, dem 12.09.2023 um 17:42 +0200 schrieb Oleg Kalnichevski: > http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java?revision=1422573=markup > > Oleg That confirms my statement, look at the imports, there

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On Tue, 2023-09-12 at 17:36 +0200, Torsten Krah wrote: > > > > You do not. > > Looking at [1] the http classes (e.g. [2]) do not leverage the > java.net.http classes, so at least on that part I do remember right, > imho. >

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

> > You do not. Looking at [1] the http classes (e.g. [2]) do not leverage the java.net.http classes, so at least on that part I do remember right, imho. [1] http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/java/org/apache/commons/httpclient/ [2]

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On Tue, 2023-09-12 at 15:06 +, Michael Osipov wrote: > On 2023/09/12 14:53:52 Torsten Krah wrote: > > Am Dienstag, dem 12.09.2023 um 14:39 + schrieb Michael Osipov: > > > How, did you expect us to write an custom JSSE provider? > > > > The old pre 4.x http components had their own http

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On 2023/09/12 14:53:52 Torsten Krah wrote: > Am Dienstag, dem 12.09.2023 um 14:39 + schrieb Michael Osipov: > > How, did you expect us to write an custom JSSE provider? > > The old pre 4.x http components had their own http classes and did not > use the JSSE base ones - if I remember right -

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

Am Dienstag, dem 12.09.2023 um 14:39 + schrieb Michael Osipov: > How, did you expect us to write an custom JSSE provider? The old pre 4.x http components had their own http classes and did not use the JSSE base ones - if I remember right - for their implementation, so it seemed not that

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On 2023/09/12 14:35:08 Torsten Krah wrote: > Am Dienstag, dem 12.09.2023 um 14:21 + schrieb Michael Osipov: > > PHA is not implemented in SunJSSE. > > Yeah, I found https://bugs.openjdk.org/browse/JDK-8206923 - > unfortunately no progress on that ticket so far - but I hade hope that >

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

Am Dienstag, dem 12.09.2023 um 14:21 + schrieb Michael Osipov: > PHA is not implemented in SunJSSE. Yeah, I found https://bugs.openjdk.org/browse/JDK-8206923 - unfortunately no progress on that ticket so far - but I hade hope that HttpComponents brought its own impl which I could opt-in to

Re: How to enable TLS 1.3 post-handshake authentication with HTTP 1.1

On 2023/09/12 13:54:49 Torsten Krah wrote: > Hi, > > how do I enable TLS 1.3 post-handshake authentication with HTTP 1.1 > when using HttpComponents? > > At the moment all my requests are failing if a TLS 1.3 host requires > mutual tls and the certificate is only required for some methods / >

Re: HttpEntity cleanup - possible bugs?

On 8/31/23 3:55 AM, Oleg Kalnichevski wrote: And that the EntityUtils#consume call in the CloseableHttpClient is really just there for the case of an improperly written handler that doesn't do that, and solely so that the connection can be reused? Correct. It is an extra safety net. Ok,

Re: org.apache.http.concurrent.FutureCallback: Exception handling

On Thu, 2023-08-31 at 11:32 +0200, Konrad Windszus wrote: > Hi Oleg, > Thanks for the input. > > > On 31. Aug 2023, at 11:17, Oleg Kalnichevski > > wrote: > > > > On Thu, 2023-08-31 at 10:08 +0200, Konrad Windszus wrote: > > > Hi, > > > I can pass a FutureCallback implementation to > > >

Re: org.apache.http.concurrent.FutureCallback: Exception handling

Hi Oleg, Thanks for the input. > On 31. Aug 2023, at 11:17, Oleg Kalnichevski wrote: > > On Thu, 2023-08-31 at 10:08 +0200, Konrad Windszus wrote: >> Hi, >> I can pass a FutureCallback implementation to >> HttpAsyncClient.execute(…). >> However the javadoc at >>

Re: org.apache.http.concurrent.FutureCallback: Exception handling

On Thu, 2023-08-31 at 10:08 +0200, Konrad Windszus wrote: > Hi, > I can pass a FutureCallback implementation to > HttpAsyncClient.execute(…). > However the javadoc at > https://hc.apache.org/httpcomponents-core-5.1.x/current/httpcore5/apidocs/org/apache/hc/core5/concurrent/FutureCallback.html >  

Re: HttpEntity cleanup - possible bugs?

On Wed, 2023-08-30 at 16:33 -0400, Brent Putman wrote: > > On 8/30/23 5:00 AM, Oleg Kalnichevski wrote: > > > > Again. It is called to make sure the entity has been fully consumed > > and > > the underlying connection the entity has been streaming its conte

Re: HttpEntity cleanup - possible bugs?

On 8/30/23 5:00 AM, Oleg Kalnichevski wrote: Again. It is called to make sure the entity has been fully consumed and the underlying connection the entity has been streaming its content from is fully re-usable. So in the case of an unchecked RuntimeException or other Throwable, that means

Re: HttpEntity cleanup - possible bugs?

On Tue, 2023-08-29 at 18:55 -0400, Brent Putman wrote: > > On 8/29/23 3:48 AM, Oleg Kalnichevski wrote: > > > > This code is not about connection clean-up, this code is about > > connection re-use. The resource clean-up is ensured by closing out > > the > >

Re: HttpEntity cleanup - possible bugs?

On 8/29/23 3:48 AM, Oleg Kalnichevski wrote: This code is not about connection clean-up, this code is about connection re-use. The resource clean-up is ensured by closing out the response. Ok, but then why is EntityUtils.consume(entity) being called at all? Seems like it's either necessary

Re: HttpEntity cleanup - possible bugs?

is > more > // important and will be thrown to the caller. > LOG.warn("Error consuming content after an > exception.", t2); > } > throw new ClientProtocolException(t); > } >   

Re: How Do I Set SNI(Server Name Indentification)

On Sat, 2023-08-12 at 12:27 +0300, Petar Tahchiev wrote: > Yes, > like I already mentioned it is not a SNI problem. > > Because I was using PoolingAsyncClientConnectionManager I decided to > replace it with PoolingHttpClientConnectionManager and it worked. So > the > problem is not in the SNI but

Re: How Do I Set SNI(Server Name Indentification)

Yes, like I already mentioned it is not a SNI problem. Because I was using PoolingAsyncClientConnectionManager I decided to replace it with PoolingHttpClientConnectionManager and it worked. So the problem is not in the SNI but in the PoolingAsyncClientConnectionManager. I am following this guide

Re: How Do I Set SNI(Server Name Indentification)

I see no evidence of SNI not working: try (final CloseableHttpAsyncClient client = HttpAsyncClients.custom() .build()) { client.start(); final HttpHost endpoint = new HttpHost("https", InetAddress.getByName("www.google.com"), "www.google.ch", 443); final HttpClientContext

Re: How Do I Set SNI(Server Name Indentification)

On 8/10/23 14:03, Petar Tahchiev wrote: Hi Jochen, I don't have 2 different SSL certificates. I have no idea what SNI is but that seems to be the only difference in the log from curl and httpclient5. https://en.wikipedia.org/wiki/Server_Name_Indication Basically it's a feature of TLS that

Re: How Do I Set SNI(Server Name Indentification)

Hi Peter, If we can improve our migration guide, then I'm all for it. I'm not sure how to condense this into a simple before and after example though. Gary On Fri, Aug 11, 2023, 8:01 AM Petar Tahchiev wrote: > Hi Oleg, > sorry but I am new with this. "This, of course, is not going to work" -

Re: How Do I Set SNI(Server Name Indentification)

Hi Oleg, sorry but I am new with this. "This, of course, is not going to work" - what is not going to work and why not? "You need to pass HttpHost with the IP address of the physical endpoint. This cannot be done with Simple* messages. They are simple for a reason." - I don't understand this.

Re: How Do I Set SNI(Server Name Indentification)

On Fri, 2023-08-11 at 13:08 +0300, Petar Tahchiev wrote: > Hello, > > so I'm getting closer. Because I was > using PoolingAsyncClientConnectionManager I decided to replace it > with PoolingHttpClientConnectionManager and it worked. So the problem > is > not in the SNI but in the

Re: How Do I Set SNI(Server Name Indentification)

Hello, so I'm getting closer. Because I was using PoolingAsyncClientConnectionManager I decided to replace it with PoolingHttpClientConnectionManager and it worked. So the problem is not in the SNI but in the PoolingAsyncClientConnectionManager. I am following this guide exactly:

Re: How Do I Set SNI(Server Name Indentification)

On Thu, 2023-08-10 at 22:40 +0300, Petar Tahchiev wrote: > Hmm, > > I tried now setting the Host header: > > > httpGet.setHeader("Host", "localhost"); > > This is wrong. You should not be doing that. You should let HttpClient generate the Host header when appropriate. HttpClient will also

Re: How Do I Set SNI(Server Name Indentification)

Hi Jochen, I don't have 2 different SSL certificates. I have no idea what SNI is but that seems to be the only difference in the log from curl and httpclient5. This is from curl:

Re: How Do I Set SNI(Server Name Indentification)

Hi, Petar, looking through https://tomcat.apache.org/tomcat-9.0-doc/config/http.html I get the impression, that SNI is a server-side issue. So, the actual problem may be on the server side, rather than the client side. To begin with: Do you really need two different SSL certificates within

Re: How Do I Set SNI(Server Name Indentification)

Hmm, I tried now setting the Host header: httpGet.setHeader("Host", "localhost"); yet tomcat still logs null for SNI На чт, 10.08.2023 г. в 22:21 ч. Jochen Wiedmann написа: > On Thu, Aug 10, 2023 at 9:14 PM Petar Tahchiev > wrote: > > > I found this gist which tells how to provide a SNI:

Re: How Do I Set SNI(Server Name Indentification)

On Thu, Aug 10, 2023 at 9:14 PM Petar Tahchiev wrote: > I found this gist which tells how to provide a SNI: > > https://gist.github.com/jkuipers/e0b35c21c466a9b4d88a > > but it is for HttpClient4 and I am unable to migrate the code to > HttpClient5. >From looking at the gist, all that it does

Re: HTTP/2 Support with HttpClient Classic API

On Fri, 2023-07-21 at 12:18 +0200, Konrad Windszus wrote: > One more aspect on this: > Currently the documentation mentions all 3 APIs (Classic, Async, > Reactive) in parallel > (https://hc.apache.org/httpcomponents-client-5.2.x/) with no > mentioning of any deprecation. > But that means for all

Re: HTTP/2 Support with HttpClient Classic API

One more aspect on this: Currently the documentation mentions all 3 APIs (Classic, Async, Reactive) in parallel (https://hc.apache.org/httpcomponents-client-5.2.x/) with no mentioning of any deprecation. But that means for all consumers that decide for Classic API, they will (probably) never be

Re: HTTP/2 Support with HttpClient Classic API

Hi Oleg, Thanks for the quick answer. I am no expert but there are some other aspects apart from performance which may make HTTP/2 preferable, e.g. Header Compression or Connection Pooling (other means of detecting closed connections). Maybe in the future there are also endpoints that

Re: HTTP/2 Support with HttpClient Classic API

On Thu, 2023-07-20 at 15:13 +0200, Konrad Windszus wrote: > Hi, > Currently from reading > https://hc.apache.org/httpcomponents-client-5.2.x/ it seems that > there are no limitations with support of HTTP/2, on the other hand > only Async API has explicit HTTP/2 examples mentioned in >

HttpClient 5.2.2 release plans; Re: [ANNOUNCEMENT] HttpComponents Core 5.2.2 GA released

On Tue, 2023-07-18 at 10:22 +0530, Sandeep Gaur wrote: > Hi All, > > We need to update httpclient with the fix of > https://issues.apache.org/jira/browse/HTTPCORE-751, can someone > please > confirm the release plan of httpclient 5.2.2. > There are no immediate plans to release HttpClient

Re: Preemptive Basic auth with Apache HttpClient 5.2

OK, your code uses an ExecInterceptor though, not a HttpRequestInterceptor. I’ll give it a try. Cheers Giovanni From: Oleg Kalnichevski Date: Friday, 14 July 2023 at 10:24 To: HttpClient User Discussion Subject: Re: Preemptive Basic auth with Apache HttpClient 5.2 On Thu, 2023-07-13 at 17:37

Re: Preemptive Basic auth with Apache HttpClient 5.2

Utils.consume(response.getEntity()); return null; }); } } > From: Oleg Kalnichevski > Date: Thursday, 13 July 2023 at 18:29 > To: HttpClient User Discussion > Subject: Re: Preemptive Basic auth with Apache HttpClient 5.2 > On Thu

Re: Preemptive Basic auth with Apache HttpClient 5.2

July 2023 at 18:29 To: HttpClient User Discussion Subject: Re: Preemptive Basic auth with Apache HttpClient 5.2 On Thu, 2023-07-13 at 17:02 +, D'Ascola, Giovanni wrote: > I did look at the examples, but the Preemptive Basic Auth > one<https://eur02.safelinks.protection.outlook.com/?url

Re: Preemptive Basic auth with Apache HttpClient 5.2

HttpClient.execute() directly. > And why? What stops you from manipulating the execution context from an interceptor? Oleg > Giovanni > > From: Oleg Kalnichevski > Date: Thursday, 13 July 2023 at 17:03 > To: HttpClient User Discussion > Subject: Re: Preemptive Basic a

Re: Preemptive Basic auth with Apache HttpClient 5.2

17:03 To: HttpClient User Discussion Subject: Re: Preemptive Basic auth with Apache HttpClient 5.2 On Thu, 2023-07-13 at 15:27 +, D'Ascola, Giovanni wrote: > Is there a way to implement preemptive basic authentication with > Apache HttpClient 5.2 using a HttpRequestInterceptor similar t

Re: Preemptive Basic auth with Apache HttpClient 5.2

On Thu, 2023-07-13 at 15:27 +, D'Ascola, Giovanni wrote: >  Is there a way to implement preemptive basic authentication with > Apache HttpClient 5.2 using a HttpRequestInterceptor similar to how > it's done here (accepted > response)

Re: [ANNOUNCEMENT] HttpComponents Core 5.2.2 GA released

Hi Sandeep, The two components are not automatically released together, you did not miss anything. Gary On Tue, Jul 4, 2023, 03:09 Sandeep Gaur wrote: > Hi Oleg Kalnichevski, > > Regarding the http 5.2.2 release, we are using httpclient5 directly, > > httpclient5 >

Re: [ANNOUNCEMENT] HttpComponents Core 5.2.2 GA released

Hi Sandeep, The two components are not automatically released together, you did not miss anything. Gary On Tue, Jul 4, 2023, 03:09 Sandeep Gaur wrote: > Hi Oleg Kalnichevski, > > Regarding the http 5.2.2 release, we are using httpclient5 directly, > > httpclient5 >

Re: Seeing randomly DeadlineTimeoutException exception

Hi Oleg, Created HTTPCORE-754 for the same. On Thu, Jun 29, 2023 at 7:15 PM Oleg Kalnichevski wrote: > On Thu, 2023-06-29 at 15:29 +0530, sreenivas somavarapu wrote: > > Hi Oleg, > > > > The error message is misleading (See below). It looks

Re: Seeing randomly DeadlineTimeoutException exception

On Thu, 2023-06-29 at 15:29 +0530, sreenivas somavarapu wrote: > Hi Oleg, > > The error message is misleading (See below). It looks like Actual > error is because it is unable to acquire lock (From the exception > provided earlier Line 27 of StrictConnPool.java). Timeout of 0 means > don't wait

Re: Seeing randomly DeadlineTimeoutException exception

mes for a 20 minute run (And these 2 >> > > > > > files >> > > > > > are >> > > > > > during start of the test i.e., initial 1 / 2 minutes run >

Re: Seeing randomly DeadlineTimeoutException exception

ow logging configuration. Let me know if you want > > > > > > all > > > > > > those 62 > > > > > > files. > > > > > > > > > > > > logger.httpClient.name = org.apache.hc.client5.http.

Re: Seeing randomly DeadlineTimeoutException exception

> > > > logger.httpCore.level = INFO > > > > > logger.httpCore.additivity = false > > > > > logger.httpCore.appenderRef.rolling.ref = httpclientRolling > > > > > > > > > > > > > > >  httpclientt

Re: Seeing randomly DeadlineTimeoutException exception

in > > > the logs. What am I supposed to do with these logs? > > > > > > > > > oleg@ok2c:~/src/misc/httpclienttracelogs$ grep -i Timeout * > > > oleg@ok2c:~/src/misc/httpclienttrace

Re: Seeing randomly DeadlineTimeoutException exception

oleg@ok2c:~/src/misc/httpclienttracelogs$ grep -i Timeout * > > oleg@ok2c:~/src/misc/httpclienttracelogs$ grep -i exception * > > oleg@ok2c:~/src/misc/httpclienttracelogs$ > > > > > > Oleg > > > > > > > > > > On Mon, Jun 26, 2023 at

Re: Seeing randomly DeadlineTimeoutException exception

$ grep -i exception * > oleg@ok2c:~/src/misc/httpclienttracelogs$ > > > Oleg > > > > > > On Mon, Jun 26, 2023 at 9:58 PM Oleg Kalnichevski > > wrote: > > > > > On Mon, 2023-06-26 at 18:20 +0530, sreenivas somavarapu wrote: > > > > Hi Oleg, >

Re: Seeing randomly DeadlineTimeoutException exception

M Oleg Kalnichevski > wrote: > > > On Mon, 2023-06-26 at 18:20 +0530, sreenivas somavarapu wrote: > > > Hi Oleg, > > > > > > > > > > > > Hope you were able to access logs provided and in the process of > > > analyzing &g

Re: Seeing randomly DeadlineTimeoutException exception

nalyzing > > them. > > No, I was not. The URL was access protected. I requested access but no > one reacted. Anyway, it is irrelevant now. Please re-run the whole > thing with the logging settings I sent you in my previous message. > > Oleg > > >

Re: Seeing randomly DeadlineTimeoutException exception

On Mon, 2023-06-26 at 18:20 +0530, sreenivas somavarapu wrote: > Hi Oleg, > > > > Hope you were able to access logs provided and in the process of > analyzing > them.  No, I was not. The URL was access protected. I requested access but no one reacted. Anyway, it is irre

Re: Seeing randomly DeadlineTimeoutException exception

Hi Oleg, Hope you were able to access logs provided and in the process of analyzing them. Just a bit of information which might be useful in analyzing. We are using *execute* method of *HttpAsyncClient* by passing *HttpContext* parameter. Below is how we are constructing *HttpContext* object.

Re: Question about max connections

On Mon, 2023-06-26 at 11:13 +0200, Joan grupoventus wrote: > Hi Oleg, > > > > So it works perfectly, 1 request sent OK and the another fails > because max_connections was exceeded. > > It seems that changing the maxConnectionPerRoute does not work on > runtime ONLY when the concurrency policy

RE: Question about max connections

ust let me know what you think. Thanks, Joan. -Original Message- From: Oleg Kalnichevski Sent: Friday, June 23, 2023 12:04 PM To: HttpClient User Discussion Subject: Re: Question about max connections On Fri, 2023-06-23 at 11:52 +0200, Joan grupoventus wrote: > Hi Oleg, > > In

Re: Question about max connections

age- > From: Oleg Kalnichevski > Sent: Friday, June 23, 2023 11:28 AM > To: HttpClient User Discussion > Subject: Re: Question about max connections > > On Fri, 2023-06-23 at 11:23 +0200, Joan grupoventus wrote: > > Hello, > > >

RE: Question about max connections

fly, or after modifying it I need to restart the pool to apply the new value. Thanks, Joan. -Original Message- From: Oleg Kalnichevski Sent: Friday, June 23, 2023 11:28 AM To: HttpClient User Discussion Subject: Re: Question about max connections On Fri, 2023-06-23 at 11:23 +0200, J

Re: Question about max connections

On Fri, 2023-06-23 at 11:23 +0200, Joan grupoventus wrote: > Hello, > > We have an async http pool with LAX concurrency (httpclient 5.2.1): > this.phccm = > PoolingAsyncClientConnectionManagerBuilder.create().setPoolConcurrenc > yPolicy(PoolConcurrencyPolicy.LAX).build(); > > We set the max

Re: Seeing randomly DeadlineTimeoutException exception

On Thu, 2023-06-22 at 22:46 +0530, sreenivas somavarapu wrote: > Hi Oleg, > > PFA httpclient logs attached. I have provided 4 instances of errors > along > with a time stamp (due to file sizes attached to respective log files > in zip file) which are below during our load test. Please let me know

Re: Seeing randomly DeadlineTimeoutException exception

Hi Oleg, PFA httpclient logs attached. I have provided 4 instances of errors along with a time stamp (due to file sizes attached to respective log files in zip file) which are below during our load test. Please let me know if any other logging is required. My environment consists of (All Windows

Re: Seeing randomly DeadlineTimeoutException exception

Your best bet is to provide a failing unit test, either as a PR on GitHub or a standalone Java file or Maven project attached to a Jira ticket. Gary On Tue, Jun 20, 2023, 12:44 sreenivas somavarapu wrote: > Hi Team, > > I am running a lod test using an Async HTTPClient. Even within 1 minutes

Re: Seeing randomly DeadlineTimeoutException exception

On Tue, 2023-06-20 at 22:12 +0530, sreenivas somavarapu wrote: > Hi Team, > > I am running a lod test using an Async HTTPClient. Even within 1 > minutes of > load test randomly getting below exception causing transaction to > fail. > Using most of the defaults for HTTPClient with below

  1   2   3   4   5   6   7   8   9   10   >