Клиент Apache Camel https4 не использует один и тот же порт TCP для нескольких запросов с keepAlive = true - PullRequest
Новая
       22

Клиент Apache Camel https4 не использует один и тот же порт TCP для нескольких запросов с keepAlive = true

0 голосов
/ 31 октября 2018

Привет! Я использую Apache Camel http4 компонент для отправки https запроса с keepAlive=true, но когда я вижу netstat после отправки нескольких запросов, я вижу, что каждый запрос открывает новый TCP-порт для однорангового соединения.
Я чувствую, что это не должно быть обычным поведением транзакций keepAlive , почему тот же TCP-порт не используется повторно для связи с сервером и как этого можно достичь, если это вообще возможно будет.

Ответы [ 2 ]

0 голосов
/ 21 декабря 2018

Оказывается, это не проблема поддержания жизни; соединения фактически поддерживаются в рабочем состоянии. Проблема состоит в том, что соединения как часть пула, управляемого по умолчанию PoolingHttpClientConnectionManager, не использовались повторно. Обе вещи можно было легко увидеть, включив протоколирование для Apache HttpClient (который используется под капотом):

Keep-Alive используется:

2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "HTTP / 1.1 200 OK [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] провод - http-outgoing-7 << "Keep-Alive: timeout = 5, max = 300 [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "Сервер: Apache-Coyote / 1.1 [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "Content-Encoding: gzip [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "Vary: Accept-Encoding [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "Cluster-Id: A [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] телеграмма - http-outgoing-7 << "Дата: ср., 19 декабря 2018 06:59:17 GMT [\ r] [\ n]" 2018/12/19 07: 59: 17: 470 CET [DEBUG] - http-outgoing-7 << "Content-Type: text / xml [\ r] [\ n]" 2018/12/19 07: 59: 17: 471 CET [DEBUG] провод - http-outgoing-7 << "Длина контента: 239 [\ r] [\ n]" 2018/12/19 07: 59: 17: 471 CET [DEBUG] провод - http-outgoing-7 << "[\ r] [\ n]" Соединения не используются повторно: </p>

2018/12/19 08: 00: 08: 240 CET [DEBUG] PoolingHttpClientConnectionManager - Запрос соединения: [route: {s} -> https://someurl.com:443][total поддерживается: 1; выделенный маршрут: 1 из 1; Всего выделено: 1 из 1] 2018/12/19 08: 00: 08: 240 CET [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-7: Закрыть соединение 2018/12/19 08: 00: 08: 242 CET [DEBUG] PoolingHttpClientConnectionManager - Соединение арендовано: [id: 8] [route: {s} -> https://someurl.com:443][total поддерживается: 0; выделенный маршрут: 1 из 1; Всего выделено: 1 из 1] Обратите внимание, что можно легко включить ведение журнала для HttpClient, передав несколько аргументов JVM при запуске.

Так почему же тогда соединения не используются повторно? Это связано с тем, что используется SSL, а PoolingHttpClientConnectionManager, используемый HttpClient Apache, не позволяет повторное использование соединения в случае, если основной пользователь из существующего соединения отличается от запрошенного соединения (облегчено DefaultUserTokenHandler). Смотрите также, например, этот пост Stackoverflow Решение состоит в том, чтобы реализовать пользовательский UserTokenHandler (или использовать NullTokenHandler, если этого достаточно) и соответственно настроить HttpClientBuilder.

0 голосов
/ 02 ноября 2018

Вы уже проанализировали заголовки ответа HTTP , чтобы проверить, учитывается ли KeepAlive и с каким значением времени ожидания.

Пример ожидаемого ответа: 

HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=10, max=20
Content-Type: text/html; charset=UTF-8
Date: ...
Content-Length: ...
...