Застревание в SocketInputStream.socketRead0

Question

Застревание в SocketInputStream.socketRead0

1

У меня есть проект, в котором я загружаю много страниц одновременно во многих задачах, которые обрабатываются через ThreadPool (size = 200). Все эти задачи используют тот же метод getPage для загрузки страницы (с Apache Commons HttpClient и Apache Commons IO):

public static String getPage(String url)
        throws IOException {

    HttpUriRequest request = new HttpGet(url);

    HttpResponse response = HTTP_CLIENT_BUILDER.build().execute(request);
    try (InputStream content = response.getEntity().getContent()) {
        return IOUtils.toString(content, "UTF-8");
    }
}

в то время как HTTP_CLIENT_BUILDER - это статическое поле, инициализированное следующим образом:

 private static final HttpClientBuilder HTTP_CLIENT_BUILDER = HttpClients.custom()
        .setDefaultRequestConfig(RequestConfig.custom()
                .setSocketTimeout(SOCKET_TIMEOUT_MS) // 60_000
                .setConnectTimeout(CONNECTION_TIMEOUT_MS) // 5_000
                .build());

Заявление о проблемах: в какой-то момент (когда большая часть задач завершена) все остальные потоки застревают в собственном методе SocketInputStream.socketRead0, поэтому jdb говорит, что все они работают (хм, да, я ожидаю, что поведение с использованием собственного метода :-)):

> threads
Group system:
  (java.lang.ref.Reference$ReferenceHandler)0xac4 Reference Handler cond. waiting
  (java.lang.ref.Finalizer$FinalizerThread)0xac5  Finalizer         cond. waiting
  (java.lang.Thread)0xac6                         Signal Dispatcher running
  (java.lang.Thread)0xac7                         Java2D Disposer   cond. waiting
Group main:
  (java.lang.Thread)0xac9                         pool-1-thread-5   running
  (java.lang.Thread)0xaca                         pool-1-thread-12  running
  (... 12 more threads from ThreadPool ...)
  (java.lang.Thread)0xad7                         DestroyJavaVM     running
> where 0xac9
  [1] java.net.SocketInputStream.socketRead0 (native method)
  [2] java.net.SocketInputStream.read (SocketInputStream.java:150)
  [3] java.net.SocketInputStream.read (SocketInputStream.java:121)
  [4] sun.security.ssl.InputRecord.readFully (InputRecord.java:465)
  [5] sun.security.ssl.InputRecord.read (InputRecord.java:503)
  [6] sun.security.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:961)
  [7] sun.security.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.java:1,363)
  [8] sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1,391)
  [9] sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1,375)
  [10] org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket (SSLConnectionSocketFactory.java:275)
  [11] org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket (SSLConnectionSocketFactory.java:254)
  [12] org.apache.http.impl.conn.HttpClientConnectionOperator.connect (HttpClientConnectionOperator.java:117)
  [13] org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect (PoolingHttpClientConnectionManager.java:314)
  [14] org.apache.http.impl.execchain.MainClientExec.establishRoute (MainClientExec.java:363)
  [15] org.apache.http.impl.execchain.MainClientExec.execute (MainClientExec.java:219)
  [16] org.apache.http.impl.execchain.ProtocolExec.execute (ProtocolExec.java:195)
  [17] org.apache.http.impl.execchain.RetryExec.execute (RetryExec.java:86)
  [18] org.apache.http.impl.execchain.RedirectExec.execute (RedirectExec.java:108)
  [19] org.apache.http.impl.client.InternalHttpClient.doExecute (InternalHttpClient.java:186)
  [20] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:82)
  [21] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:106)
  [22] <package>.Utils.getPage (Utils.java:122)
  [23...] <internal details>
> # the same picture for all of them

Я не понимаю, почему это может произойти, но я нашел ошибку Java, которая, возможно, связана с проблемой. Так что, возможно, я не ищу реального решения, но для некоторого обходного пути.

Поскольку ошибка была подана против Linux, я должен сказать, что я также использую виртуальную машину с Ubuntu 14.04 x86_64

UPD: ОК, то, что я пробовал сейчас, добавляет новый тайм-аут с помощью setConnectionRequestTimeout (просто чтобы убедиться, что он не работает) добавьте finally блок с помощью getPage:

...
try (InputStream content = response.getEntity().getContent()) {
    return IOUtils.toString(content, "UTF-8");
} finally {
   httpClient.getConnectionManager().closeIdleConnections(0, TimeUnit.NANOSECONDS);
}

Давайте посмотрим, если это поможет.

UPD2: это, по-видимому, немного помогает, но все же у меня есть такие постоянные задачи, которые застревают примерно один раз в день.

Dmitry Ginzburg 26 март 2015, в 11:30

Источник

0

Socket.read который делает Socket.read будет отображаться как Runnable , см. Этот пост SO: stackoverflow.com/questions/12544212 . Скорее всего, удаленная сторона держит свой конец сокета открытым, поэтому ваши задачи не могут быть завершены. Например, вы отправили Executor больше задач, чем необходимо для загрузки удаленных ресурсов, и оставшаяся бездействующая задача остается в ожидании.
Victor Sorokin 26 март 2015, в 09:41
0

@VictorSorokin, этого не должно произойти, поскольку я установил таймауты (см. Инициализатор для HTTP_CLIENT_BUILDER )
Dmitry Ginzburg 26 март 2015, в 09:44
0

Да, забыли, извините. Затем я проверил бы соединение с tcpdump или аналогичным, чтобы понять, что поддерживает TCP-соединение. Возможно, журналы на стороне сервера также могут быть полезны.
Victor Sorokin 26 март 2015, в 09:55
0

Затем, как только вы узнаете (каким-то образом), что все загружено, закройте открытые розетки на вашей стороне. Это освободит потоки пула и застрявшие задачи будут отменены (за исключением). Это подразумевает, что вам нужно поместить открытые сокеты в некоторую общую коллекцию внутри getPage , которая должна быть доступна для задачи отмены.
Victor Sorokin 26 март 2015, в 10:02
0

@VictorSorokin Сами сокеты - это детали реализации под капотом HttpClient, поэтому я не уверен, как их получить. Кроме того, мне кажется, что создание такой коллекции - это большое излишество.
Dmitry Ginzburg 26 март 2015, в 10:16
0

Это очень распространенная проблема, и я сбит с толку, как это все еще не исправлено Apache
Arya 22 окт. 2016, в 05:22

Показать ещё 4 комментария

Теги:

java

sockets

apache-commons-httpclient

1 ответ

Ещё вопросы

Socket.read который делает Socket.read будет отображаться как Runnable , см. Этот пост SO: stackoverflow.com/questions/12544212 . Скорее всего, удаленная сторона держит свой конец сокета открытым, поэтому ваши задачи не могут быть завершены. Например, вы отправили Executor больше задач, чем необходимо для загрузки удаленных ресурсов, и оставшаяся бездействующая задача остается в ожидании.
@VictorSorokin, этого не должно произойти, поскольку я установил таймауты (см. Инициализатор для HTTP_CLIENT_BUILDER )
Да, забыли, извините. Затем я проверил бы соединение с tcpdump или аналогичным, чтобы понять, что поддерживает TCP-соединение. Возможно, журналы на стороне сервера также могут быть полезны.
Затем, как только вы узнаете (каким-то образом), что все загружено, закройте открытые розетки на вашей стороне. Это освободит потоки пула и застрявшие задачи будут отменены (за исключением). Это подразумевает, что вам нужно поместить открытые сокеты в некоторую общую коллекцию внутри getPage , которая должна быть доступна для задачи отмены.
@VictorSorokin Сами сокеты - это детали реализации под капотом HttpClient, поэтому я не уверен, как их получить. Кроме того, мне кажется, что создание такой коллекции - это большое излишество.
Это очень распространенная проблема, и я сбит с толку, как это все еще не исправлено Apache

Dmitry Ginzburg · Accepted Answer · 2015-05-05T15-15-00.000Z

К сожалению, мне не удалось найти какое-либо проворное решение (или реальное решение), поэтому у меня есть менеджер, чтобы написать собственное обходное решение, я надеюсь, что это поможет кому-то с этой ошибкой:

Создать класс ConnectionSupervisor:

private static class ConnectionsSupervisor extends Thread {
    private Set<RequestEntry> streams = new CopyOnWriteArraySet<>();

    public ConnectionsSupervisor() {
        setDaemon(true);
        setName("Connections supervisor");
    }

    @Override
    public void run() {
        while (true) {
            try {
                Thread.sleep(CONNECTIONS_SUPERVISOR_WAIT_MS);
            } catch (InterruptedException ignored) {
            }
            long time = timestamp();
            streams.stream().filter(entry -> time > entry.timeoutBorder).forEach(entry -> {
                HttpUriRequest request = entry.request;
                System.err.format("HttpUriRequest killed after timeout (%d sec.) exceeded: %s%n",
                        FULL_CONNECTION_TIMEOUT_S,
                        request);
                request.abort();
            });
        }
    }

    public void addRequest(HttpUriRequest request) {
        streams.add(new RequestEntry(timestamp() + FULL_CONNECTION_TIMEOUT_S, request));
    }

    public void removeRequest(HttpUriRequest request) {
        streams.removeIf(entry -> entry.request == request);
    }

    private static class RequestEntry {
        private long timeoutBorder;
        private HttpUriRequest request;

        public RequestEntry(long timeoutBorder, HttpUriRequest request) {
            this.timeoutBorder = timeoutBorder;
            this.request = request;
        }
    }
}


public static long timestamp() {
    return Instant.now().getEpochSecond();
}

Где-то должен быть экземпляр ConnectionSupervisor, что-то вроде:

private static final ConnectionsSupervisor connectionsSupervisor = new ConnectionsSupervisor();
static {
    connectionsSupervisor.start();
}

В чем-то вроде метода getPage:

HttpUriRequest request = ...;

// ...

connectionsSupervisor.addRequest(request);

try (InputStream content = httpClient.execute(request).getEntity().getContent()) {
    return IOUtils.toString(content, "UTF-8");
    // or any other usage
} finally {
    connectionsSupervisor.removeRequest(request);
    // highly important!
}