Что такое idleTimeout по умолчанию в веб-клиенте Jetty? - PullRequest
0 голосов
/ 11 июля 2019

Мы используем Spring Reactive WebClient для выполнения http-вызовов. Он использует JettyClientHttpConnector внизу. Периодически он начинает выдавать исключение EOF при отправке запроса на внешний сервер.

После некоторого онлайн-поиска исключений создается впечатление, что соединение может быть закрыто сервером. Однако я не могу найти то, что по умолчанию idleTimeout, который использует веб-клиент Jetty. Я хочу знать значение idletimeout, прежде чем добавлять фиксированное значение в производственный код и ломать его

return webclient.post()
        .uri(url)
        .header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
        .header(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON_VALUE)
        .syncBody(request)
        .retrieve()
        .bodyToMono(responseType)

        });

No exception handler found for exception java.io.EOFException: HttpConnectionOverHTTP@78adba37::DecryptedEndPoint@39cf23c5{sfp-prod-1.infra.marcus.com/10.207.63.102:3128\u003c-\u003e/10.255.50.84:36250,OPEN,fill=-,flush=C,to=416480/0}
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF(HttpReceiverOverHTTP.java:338) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1551) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.shutdown(HttpReceiverOverHTTP.java:209) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:147) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155) [jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
        at java.lang.Thread.run(Thread.java:748) [na:1.8.0_192]

1 Ответ

0 голосов
/ 18 июля 2019

Давайте посмотрим на 3 строки в верхней части вашего исключения.

Во-первых, у вас есть ...

Не найден обработчик исключений для исключения java.io.EOFException: HttpConnectionOverHTTP @ 78adba37 :: DecryptedEndPoint @ 39cf23c5 {sfp-prod-1.infra.marcus.com/10.207.63.102:3128\u003c-\u003e/10.255.50.84:36250,OPEN,fill = -, утопленного = C, к = 416480/0}

Это говорит о том, что у вас есть ОТКРЫТОЕ соединение, преждевременно не закрытое.

Следующая строка ...

org.eclipse.jetty.client.http.HttpReceiverOverHTTP.earlyEOF (HttpReceiverOverHTTP.java:338) [jetty-client-9.4.14.v20181114.jar: 9.4.14.v20181114]

говорит нам, что у вас ранняя ситуация с EOF, обычно это намек на сбой протокола HTTP.

org.eclipse.jetty.http.HttpParser.parseNext (HttpParser.java:1551) ~ [jetty-http-9.4.14.v20181114.jar: 9.4.14.v20181114]

Эта строка в коде говорит нам, что ваш клиент анализирует HTTP-ответ с другой стороны, этот ответ использует "chunked" Transfer-Encoding, он проанализировал окончательный закрывающий Chunk 0\r\n\r\n, но буфер чтения содержал больше байтов, что является нарушением спецификации HTTP.

WebClient сообщает через EOF, что протокол HTTP достиг EOF, но все еще есть данные, которые еще не были прочитаны. Это условие также означает, что протокол HTTP для этого соединения, как известно, является недействительным, и соединение ДОЛЖНО быть принудительно закрыто.

В этом состоянии соединение было закрыто, и данные после закрытия фрагмента были возвращены как EOFException.

...