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: [email protected] 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: [email protected]
For additional commands, e-mail: [email protected]
