[External] : Re: AssertionError in ResponseSubscribers.HttpResponseInputStream.read() in J11 only

Tue Oct 4 16:48:37 UTC 2022

Oh my - the problem wrt TCP-connection-reset is in front of the computer. Looks like I unintentionally added some “soft dead lock” kinda thingy…

I was looking for a way to use BodyPublisher backed by a java.io <http://java.io/>.OutputStream (because there’s no async variant immediately available from Jackson). So I used a SubmissionPublisher that writes all data (custom OutputStream delegating to SubmissionPublisher.write) - synchronously from inside the subscribe() method - it felt wrong when I initially wrote it, but I later totally forgot about it. So yea - no surprise that things got confused with that. The TCP connection reset was then probably some indirect consequence of that.

Sorry for the false alarm.

> On 4. Oct 2022, at 18:09, Robert Stupp <snazy at snazy.de> wrote:
> 
> Hi Daniel,
> 
> Nope, those are unrelated.
> 
> And yes, the client’s using HTTP/1.1. I probably hit the AE in the reproducer, because the reproducer’s using `InputStream.readAllBytes()`, which the “original” code cannot (have to stay on Java 8 there - sigh).
> 
> I doubt it’s related to keep-alive, because it happens within a millisecond or quicker (the HTTP request processing for that test is rather “stupidly simple”).
> 
> Robert
> 
>> On 4. Oct 2022, at 17:34, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> 
>> Hi Robert,
>> 
>> Are the assertion error and the connection reset linked?
>> I mean - if an assertion error occurs then it's anyone guess
>> what could happen next - as the behavior at that point
>> becomes undefined.
>> 
>> Otherwise connection reset usually means that the connection
>> was closed while data remained in the pipe.
>> I am assuming the underlying protocol is HTTP/1.1?
>> 
>> The HttpClient has a rather large HTTP/1.1 keep alive timeout [1],
>> so it could happen that the server keep alive expires before the
>> client, causing the server to close the connection while the client
>> is trying to reuse it. If some data has been sent but not delivered
>> at that point it might explain the reset.
>> If that's the case, tuning the keep-alive timeout on the
>> client side to expire before the server's might help.
>> 
>> best regards,
>> 
>> -- daniel
>> [1] jdk.httpclient.keepalive.timeout in https://docs.oracle.com/en/java/javase/17/core/java-networking.html
>> 
>> On 04/10/2022 16:18, Robert Stupp wrote:
>>> The issue that drives me crazy is the TCP connection reset one. Do you have any idea what might cause it? It doesn’t happen with other HTTP clients (Apache or HttpURLConnection). What I see for the TCP connection resets is always something like this (stack trace from Java 11). With the reproducer I’m trying to build I want to get Jackson and other stuff out of the game.
>>> Caused by: java.io.IOException: closed
>>> 	at java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:368)
>>> 	at java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:403)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._loadMore(UTF8StreamJsonParser.java:220)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._loadMoreGuaranteed(UTF8StreamJsonParser.java:2401)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2486)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishAndReturnString(UTF8StreamJsonParser.java:2466)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:297)
>>> 	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextTextValue(UTF8StreamJsonParser.java:1281)
>>> 	at com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:192)
>>> 	... 100 more
>>> Caused by: java.io.IOException: chunked transfer encoding, state: READING_DATA
>>> 	at java.net.http/jdk.internal.net.http.common.Utils.wrapWithExtraDetail(Utils.java:330)
>>> 	at java.net.http/jdk.internal.net.http.Http1Response$BodyReader.onReadError(Http1Response.java:758)
>>> 	at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.checkForErrors(Http1AsyncReceiver.java:297)
>>> 	at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:263)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
>>> 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>> 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>> 	at java.base/java.lang.Thread.run(Thread.java:829)
>>> Caused by: java.io.IOException: Connection reset by peer
>>> 	at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>>> 	at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>>> 	at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>>> 	at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:245)
>>> 	at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>>> 	at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube.readAvailable(SocketTube.java:1153)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:821)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube$SocketFlowTask.run(SocketTube.java:175)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
>>> 	at java.net.http/jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:763)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:941)
>>> 	at java.net.http/jdk.internal.net.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:245)
>>> 	at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:957)
>>> 	at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.lambda$run$3(HttpClientImpl.java:912)
>>> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
>>> 	at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:912)
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20221004/9e4c1a9f/attachment-0001.htm>