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.<ConnectionSocketFactory>
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? Is there any significant change in
the way the connections are getting validated?
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.
