On Wed, 2023-01-04 at 15:47 +0000, Stankov. Yavor wrote:
> Hi all,
> 
> I'm having some issues after I updated to the latest versions of hc-
> core(5.2) and hc-client (5.2).
> 
> It all started with a NPE that I started receiving in the automation
> tests that we have. The NPE appeared when I try to parse the response
> using the DefaultHttpResponseParser. I saw that actually the parse
> method is now returning null if the stream is empty instead of
> throwing an exception as it was in previous versions. Since for my
> needs I need to keep the old behavior, I just implemented some logic
> to throw the old exception in this case. So something like this:
> 
>         final ClassicHttpResponse response =
> responseParser.parse(inbuffer, is);
> 
>         if (response == null)
>         {
>             throw new NoHttpResponseException("The target server
> failed to respond");
>         }
> 
> But after this, I started getting issues with one of the tests. I
> started getting this exception, but not on each run, it happens
> sporadically (in like 60-70% of the time).
> Since I'm using keep alive (connection re-usage), my first guess was
> that some broken connection is getting used. And in fact in the logs
> I can see that a connection to the same route is being reused
> multiple times until we get this exception.
> 
> I checked that such issues could be solved by setting
> .setValidityAfterInactivity() to the connection manager, but the
> thing is that I've already set it to 5 seconds. Anyway,  I saw that
> this method is deprecated and that is why I changed it and now set it
> to the DefaultConnectionConfig. This also doesn't help. Here you can
> see what is the current configuration of the ConnectionManager:
> 
>         conMan = new
> PoolingHttpClientConnectionManager(RegistryBuilder.<ConnectionSocketF
> actory> create().register("http", new
> CustomStrictSocketFactory()).register("https", new
> CustomStrictSSLSocketFactory()).build(),
>                                                                      
>                                     new
> CustomHTTPConnectionFactory(),
>                                                                      
>                                    
> DefaultSchemePortResolver.INSTANCE,
>                                                                      
>                                     null,
>                                                                      
>                                     -1,
>                                                                      
>                                     TimeUnit.SECONDS);
>         conMan.setDefaultMaxPerRoute(getMaxConnectionsPerHost());
>         conMan.setMaxTotal(getMaxTotalConnections());
>         conMan.setDefaultConnectionConfig(ConnectionConfig.custom()
>                                                          
> .setValidateAfterInactivity(TimeValue.of(5000,
> TimeUnit.MILLISECONDS))
>                                                          
> .setConnectTimeout(Timeout.of(getConnectionTimeout(),
> TimeUnit.SECONDS))
>                                                           .build());
> 
> There are no changes in the failing test case for years. There are no
> changes in all backend logic involved in it, at least for the last
> few weeks. The only change was the update of the runtime to hc-core
> 5.2 and hc-client 5.2
> 
> By the way, I tried to update to hc-client 5.2.1, but the issue is
> still there.
> 
> My question is - is there some new configuration that is needed in
> case to be sure that no stale connections will be used?

No, there is no extra configuration required other than
ConnectionConfig.


>  Is there any significant change in the way the connections are
> getting validated?

None I can think of. The classic transport does not change much. All
changes in the 5.2 series were async transport related or about
configuration flexibility.

Oleg


> Does anyone else experience such issues?  In general any ideas and
> information will be helpful!
> 
> Best Regards,
> Yavor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas,
> Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Fe?enbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of
> the SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de              
> Registergericht/Commercial Register:
> e-mail: i...@seeburger.de               HRB 240708 Mannheim
> 
> 
> Dieses E-Mail ist nur f?r den Empf?nger bestimmt, an den es gerichtet
> ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
> Material enthalten. Jegliche darin enthaltene Ansicht oder
> Meinungs?u?erung ist die des Autors und stellt nicht notwendigerweise
> die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der
> Empf?nger, so haben Sie diese E-Mail irrt?mlich erhalten und jegliche
> Verwendung, Ver?ffentlichung, Weiterleitung, Abschrift oder jeglicher
> Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG
> noch der Absender (Stankov. Yavor) ?bernehmen die Haftung f?r Viren;
> es obliegt Ihrer Verantwortung, die E-Mail und deren Anh?nge auf
> Viren zu pr?fen.
> 
> 
> This email is intended only for the recipient(s) to whom it is
> addressed. This email may contain confidential material that may be
> protected by professional secrecy. Any fact or opinion contained, or
> expression of the material herein, does not necessarily reflect that
> of SEEBURGER AG. If you are not the addressee or if you have received
> this email in error, any use, publication or distribution including
> forwarding, copying or printing is strictly prohibited. Neither
> SEEBURGER AG, nor the sender (Stankov. Yavor) accept liability for
> viruses; it is your responsibility to check this email and its
> attachments for viruses.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to