Проміжна помилка Apache HttpClient: NoHttpResponseException

У мене є веб-служба, яка приймає метод POST із XML. Це працює нормально, то в деяких випадкових випадках, він не може зв'язатись із сервером, викидаючи IOException із повідомленням The target server failed to respond. Подальші дзвінки працюють нормально.

Це трапляється здебільшого, коли я роблю кілька дзвінків, а потім залишаю програму в режимі очікування приблизно 10-15 хв. перший виклик, який я роблю після цього, повертає цю помилку.

Я спробував кілька речей ...

Я встановлюю обробник повторної спроби, як

HttpRequestRetryHandler retryHandler = new HttpRequestRetryHandler() {

            public boolean retryRequest(IOException e, int retryCount, HttpContext httpCtx) {
                if (retryCount >= 3){
                    Logger.warn(CALLER, "Maximum tries reached, exception would be thrown to outer block");
                    return false;
                }
                if (e instanceof org.apache.http.NoHttpResponseException){
                    Logger.warn(CALLER, "No response from server on "+retryCount+" call");
                    return true;
                }
                return false;
            }
        };

        httpPost.getParams().setParameter(HttpMethodParams.RETRY_HANDLER, retryHandler);

але ця повторна спроба так і не отримала виклику. (так, я використовую речення right instanceof). При налагодженні цей клас ніколи не викликається.

Я навіть намагався налаштувати, HttpProtocolParams.setUseExpectContinue(httpClient.getParams(), false);але користі немає. Хтось може підказати, що я можу зробити зараз?

ВАЖЛИВО Окрім з'ясування, чому я отримую виняток, одне з важливих занепокоєнь у мене полягає в тому, чому тут не працює ретранслятор?

Швидше за все постійні зв’язки, які підтримує менеджер зв’язків, стають застарілими. Тобто цільовий сервер відключає з'єднання на своєму кінці, не маючи можливості HttpClient реагувати на цю подію, поки з'єднання перебуває в режимі очікування, роблячи з'єднання напівзакритим або `` застарілим ''. Зазвичай це не проблема. HttpClient використовує кілька методів для перевірки дійсності підключення після оренди з пулу. Навіть якщо перевірка застарілого з'єднання вимкнена, а застаріле з'єднання використовується для передачі повідомлення запиту, виконання запиту зазвичай не вдається в операції запису з SocketException і автоматично повторюється. Однак за деяких обставин операція запису може закінчитися без винятку, і наступна операція читання повертає -1 (кінець потоку).

Найпростіший спосіб виправити ситуацію - виселити з’єднання, термін придатності яких закінчився, і вони простоювали довше, ніж, скажімо, 1 хвилини з пулу після періоду бездіяльності. Детальніше див. У цьому розділі підручника HttpClient .

Прийнята відповідь правильна, але не має рішення. Щоб уникнути цієї помилки, ви можете додати setHttpRequestRetryHandler (або setRetryHandler для компонентів apache 4.4) для вашого HTTP-клієнта, як у цій відповіді .

HttpClient 4.4 страждав від помилки в цій області, що стосується перевірки можливо застарілих з'єднань перед поверненням до запитувача. Він не перевірив, чи з’єднання застаріло, і це в результаті негайно NoHttpResponseException.

Цю проблему вирішено в HttpClient 4.4.1. Див. Цей JIRA та примітки до випуску

В даний час більшість з'єднань HTTP вважаються постійними, якщо не зазначено інше . Однак для збереження ресурсів сервера підключення рідко залишається відкритим назавжди, час очікування підключення за замовчуванням для багатьох серверів досить короткий, наприклад, 5 секунд для Apache httpd 2.2 і вище.

org.apache.http.NoHttpResponseExceptionПомилка відбувається , швидше за все , від одного постійного з'єднання , який був закритий на сервері.

Можна встановити максимальний час, щоб залишати невикористані підключення відкритими в пулі клієнтів Apache Http, в мілісекундах.

З Spring Boot один із способів досягти цього:

public class RestTemplateCustomizers {
    static public class MaxConnectionTimeCustomizer implements RestTemplateCustomizer {

        @Override
        public void customize(RestTemplate restTemplate) {
            HttpClient httpClient = HttpClientBuilder
                .create()
                .setConnectionTimeToLive(1000, TimeUnit.MILLISECONDS)
                .build();

            restTemplate.setRequestFactory(
                new HttpComponentsClientHttpRequestFactory(httpClient));
        }
    }
}

// In your service that uses a RestTemplate
public MyRestService(RestTemplateBuilder builder ) {
    restTemplate = builder
         .customizers(new RestTemplateCustomizers.MaxConnectionTimeCustomizer())
         .build();
}

Хоча прийнята відповідь є правильною, але IMHO - це лише обхідний шлях.

Щоб бути зрозумілим: це цілком нормальна ситуація, коли постійний зв’язок може застаріти. Але, на жаль, це дуже погано, коли клієнтська бібліотека HTTP не справляється з цим належним чином.

Оскільки ця несправна поведінка в Apache HttpClient не була виправлена ​​протягом багатьох років, я, безумовно, віддав би перевагу переходу на бібліотеку, яка може легко відновитись із застарілої проблеми з підключенням, наприклад, OkHttp.

Чому?

1. OkHttp за замовчуванням об'єднує http-з'єднання.
2. Він витончено відновлюється з ситуацій, коли з’єднання http стає застарілим, і запит не може бути повторений через неімпотентність (наприклад, POST). Я не можу сказати цього про Apache HttpClient (згаданий NoHttpResponseException).
3. Підтримує HTTP / 2.0 з ранніх версій та бета-версій.

Коли я перейшов на OkHttp, мої проблеми з NoHttpResponseExceptionназавжди зникли.

Рішення : змініть стратегію повторного використання на ніколи

Оскільки ця проблема дуже складна, і існує так багато різних факторів, які можуть зазнати невдачі, я був радий знайти це рішення в іншому дописі: Як вирішити org.apache.http.NoHttpResponseException

Ніколи не використовуйте підключення повторно: налаштуйте в org.apache.http.impl.client.AbstractHttpClient:

httpClient.setReuseStrategy(new NoConnectionReuseStrategy());

Те саме можна налаштувати у конструкторі org.apache.http.impl.client.HttpClientBuilder:

builder.setConnectionReuseStrategy(new NoConnectionReuseStrategy());

Це може статися, якщо disableContentCompression()встановлено на диспетчері пулів, призначеному вашому HttpClient, а цільовий сервер намагається використовувати стиснення gzip.

Та сама проблема для мене на клієнті apache http 4.5.5, додаючи заголовок за замовчуванням

З'єднання: тісне

вирішити проблему

Я зіткнувся з тією ж проблемою, яку вирішив, додавши "connection: close" як розширення,

Крок 1: Створіть новий клас ConnectionCloseExtension

import com.github.tomakehurst.wiremock.common.FileSource;
import com.github.tomakehurst.wiremock.extension.Parameters;
import com.github.tomakehurst.wiremock.extension.ResponseTransformer;
import com.github.tomakehurst.wiremock.http.HttpHeader;
import com.github.tomakehurst.wiremock.http.HttpHeaders;
import com.github.tomakehurst.wiremock.http.Request;
import com.github.tomakehurst.wiremock.http.Response;

public class ConnectionCloseExtension extends ResponseTransformer {
  @Override
  public Response transform(Request request, Response response, FileSource files, Parameters parameters) {
    return Response.Builder
        .like(response)
        .headers(HttpHeaders.copyOf(response.getHeaders())
            .plus(new HttpHeader("Connection", "Close")))
        .build();
  }

  @Override
  public String getName() {
    return "ConnectionCloseExtension";
  }
}

Крок 2: встановіть клас розширення в wireMockServer, як показано нижче,

final WireMockServer wireMockServer = new WireMockServer(options()
                .extensions(ConnectionCloseExtension.class)
                .port(httpPort));