Hi,
>This is typically way too large. Is there any reason you want this
large total timeout?
We have operations that may 5-10 mins, however threads hung indefinitely even beyond this timeout and even shorter timeouts like 180 seconds are also hanging.
>>From where are you using the client? From a remote client, or from
within a web application deployed in Tomcat?
Yes our client runs in an application deployed inside tomcat which makes calls to remotely hosted servers.
>With "restart our servers" you mean restart the remote servers that
the client calls?
Not the remote servers, we restart appserver where jettyclient is running.
>A schematic diagram of client, load balancer, servers, etc will be
great to understand how is the system.
https://imgur.com/bxV3BA9>The thread dump does not show much.
You will have better luck registering HttpClient instances in JMX and
the performing a HttpClient dump via JMX.
This is how you do it:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.20.v20190813/jetty-client/src/test/java/org/eclipse/jetty/client/jmx/HttpClientJMXTest.javaOnce you are blocking again, you connect with a JMX console, find the
HttpClient MBean, and invoke its dump() operation to get the
HttpClient internal state.
Then attach it here for analysis.
I cannot use JMX in live production servers, so I just called
httpclient.dump() while it was hanging using a local servlet call, FYKI we instantiate a static httpclient and it will be used to establish connection with many remote servers in a multithreaded environment. PFA links below for client dumps
https://pastebin.com/N017wph4https://pastebin.com/k21hzLwL>Do you have the same problem if you don't use OpenSSL, but the
standard JDK TLS implementation?
Our framework does not support JDK 9 or above so we are dependent on conscrypt(OPENSSL) for alpn support in jdk8.
Kidnly let us know if any other details are required