On a restart of one of our services that uses this client we observed some stuck threads. A thread dump revealed that several threads are stuck in the HTTP connection the prismic API:
"http-nio-9000-exec-3" #65 daemon prio=5 os_prio=0 cpu=124345.40ms elapsed=615154.36s tid=0x00007ff0aceb1800 nid=0x2bc9 runnable [0x00007ff00c6d6000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(java.base@11.0.9.1/Native Method)
at java.net.SocketInputStream.socketRead(java.base@11.0.9.1/SocketInputStream.java:115)
at java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:168)
at java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:140)
at sun.security.ssl.SSLSocketInputRecord.read(java.base@11.0.9.1/SSLSocketInputRecord.java:476)
at sun.security.ssl.SSLSocketInputRecord.readFully(java.base@11.0.9.1/SSLSocketInputRecord.java:459)
at sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(java.base@11.0.9.1/SSLSocketInputRecord.java:243)
at sun.security.ssl.SSLSocketInputRecord.decode(java.base@11.0.9.1/SSLSocketInputRecord.java:181)
at sun.security.ssl.SSLTransport.decode(java.base@11.0.9.1/SSLTransport.java:110)
at sun.security.ssl.SSLSocketImpl.decode(java.base@11.0.9.1/SSLSocketImpl.java:1411)
at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base@11.0.9.1/SSLSocketImpl.java:1376)
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11.0.9.1/SSLSocketImpl.java:963)
at java.io.BufferedInputStream.fill(java.base@11.0.9.1/BufferedInputStream.java:252)
at java.io.BufferedInputStream.read1(java.base@11.0.9.1/BufferedInputStream.java:292)
at java.io.BufferedInputStream.read(java.base@11.0.9.1/BufferedInputStream.java:351)
- locked <0x00000000d572b678> (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(java.base@11.0.9.1/HttpClient.java:754)
at sun.net.www.http.HttpClient.parseHTTP(java.base@11.0.9.1/HttpClient.java:689)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(java.base@11.0.9.1/HttpURLConnection.java:1615)
- locked <0x00000000d572b6d0> (a sun.net.www.protocol.https.DelegateHttpsURLConnection)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base@11.0.9.1/HttpURLConnection.java:1520)
- locked <0x00000000d572b6d0> (a sun.net.www.protocol.https.DelegateHttpsURLConnection)
at java.net.URLConnection.getContent(java.base@11.0.9.1/URLConnection.java:749)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(java.base@11.0.9.1/HttpsURLConnectionImpl.java:430)
at io.prismic.core.HttpClient.fetch(HttpClient.java:41)
at io.prismic.Form$SearchForm.submit(Form.java:411)
This is happening because io.prismic.core.HttpClient#fetch uses a HttpURLConnection without specifying any timeouts. By default the underlying URLConnection has a connectTimeout and readTimeout of 0 - which means infinite.
I think this client is not maintained anymore, given the lack of updates.
This ticket serves as a warning/documentation for others.
The current code doesn't provide any methods/hooks to fix this, besides forking the code & fixing it yourself.
On a restart of one of our services that uses this client we observed some stuck threads. A thread dump revealed that several threads are stuck in the HTTP connection the prismic API:
This is happening because
io.prismic.core.HttpClient#fetch
uses aHttpURLConnection
without specifying any timeouts. By default the underlyingURLConnection
has aconnectTimeout
andreadTimeout
of0
- which meansinfinite
.I think this client is not maintained anymore, given the lack of updates. This ticket serves as a warning/documentation for others.
The current code doesn't provide any methods/hooks to fix this, besides forking the code & fixing it yourself.