Настройка:
У нас есть сайт https://Main.externaldomain/xmlservlet, который выполняет аутентификацию / проверку / геолокацию и прокси-запросы (слегка модифицированные) на http://London04.internaldomain/xmlservlet например.
Прямой доступ к внутреннему домену, доступному для конечных пользователей, отсутствует.Связь между сайтами иногда прерывается, и иногда внутренние доменные узлы становятся недоступными / мертвыми.
Главный сайт использует org.apache.http.impl.client.DefaultHttpClient (я знаю, что он устарел, мы постепеннообновление этого устаревшего кода) с readTimeout, установленным в 10.000 миллисекунд.Запрос и ответ имеют полезную нагрузку xml / тело переменной длины, и используется Transfer-Encoding: chunked, также используется Keep-Alive: timeout=15.
Проблема:
ИногдаLondon04 фактически требуется более 10 секунд (скажем, 2 минуты) для выполнения.Иногда это изящно вылетает.Иногда возникают другие (сетевые) проблемы.Иногда в течение этих 2 минут - части response-xml-данных заполняются так постепенно, что между порциями нет 10-секундного промежутка, и поэтому readTimeout никогда не превышается, иногда есть 10-секундный интервал и время ожидания HttpClient...
Мы могли бы попытаться увеличить время ожидания на главной стороне, но это могло бы легко раздувать / перегружать пул слушателей (просто обычным трафиком, даже не будучи DDOSed).Нам нужен способ различать внутренний сайт, который все еще работает над генерацией ответа, и случаи, когда он действительно аварийно завершился / network_lost / etc.И самое приятное во время разговора - это какое-то сердцебиение (каждые 5 секунд).
Мы думали, что Keep-Alive спасет нас, но, похоже, только обеспечивает разрывы между запросов (не во время запросов), и кажется, что он не вызывает пульса во время перерыва (просто наличие / wait_ для тайм-аута).
Мы думали, что chunked-кодирование может спастимы отправили несколько тактовых импульсов (0-bytes-size-chunks), чтобы дать понять другой стороне, но, похоже, нет такой реализации / реализации по умолчанию для поддержки любого тактового импульса таким образом, и более того, кажется, что 0-байтовый размер - это EODсам индикатор ...
Вопрос (ы):
Если мы правы в предположении, что KeepAlive / ChunkedEncoding не поможет нам в достижении keepAlive / hearbeat/ fastDetectionOfDeadBackend затем:
1) в каком слое должен быть реализован такой ритм?Http?tcp?
2) какие-нибудь стандартные фреймворки / библиотеки / настройки / и т. д. уже реализуют его?(если возможно: Java, REST)
ОБНОВЛЕНИЕ
Я также изучил реализации контрольных сигналов для WADL / WSDL, хотя не нашел ни одного для REST,проверил WebSockets ... Также посмотрел TCP-keepalive, которые, кажется, правильное решение для этой задачи:
НО в соответствии с теми, что я имеюустановить что-то вроде:
- tcp_keepalive_time = 5
- tcp_keepalive_intvl = 1
- tcp_keepalive_probes = 3
, который выглядит каквстречная рекомендация (2 часа - рекомендуемое, 10 минут уже представлены как нечетное значение, переход к 5 с вменяемым / безопасным, если это так - может быть, мое решение заранее ...)
также где я должен настроитьэтот?на London04 один или на мэйн тоже?(если я настрою его на Main - не затопит ли он клиента -> Main frontend communication? или могут ли NAT / etc между сайтами легко испортить намерение / поддержку keepalive?)
PS любая ссылка наRTFM приветствуется - я могу просто упустить что-то очевидное:)