2016-02-23 2 views
2

Отказ от ответственности: есть много информации по подобным темам. В нашем случае он работает, как ожидается, без AWS ELB (Elastic Load Balancer), то есть когда клиент падает, ServletOutputStream.flush() выдает исключение IOException.Обнаружение отсоединения клиента сервлета AWS ELB

Установки: у нас есть экземпляр под управлением Tomcat 7 (Java 1.7) за ELB (HTTPS: 443 -> HTTP: 8080). Сервлет передает данные клиенту через HTTP-долговременное соединение.

Проблема: когда клиент отключается, сервер сохраняет потоковые данные, то есть ServletOutputStream.flush() или .write() не бросает исключение IOException. ELB-тип «буферов» соединения (мы видим его с помощью монитора IpTraf), поэтому с стороны Tomcat он появляется, поскольку клиент все еще существует. Без ELB исключение IOException выбрано правильно, поэтому сервлет может остановить потоки. Мы отключили слив соединения и сократили время ожидания подключения до 1 секунды, мы также сократили все таймауты на HTTP-коннекторе Tomcat, включая KeepAlive, до нескольких секунд. Ничто не помогает.

Вопрос: есть ли что-нибудь, что мы можем сделать с конфигурацией ELB/Tomcat/Java, чтобы разрешить обнаружение разъединения в этой настройке?

+0

Работает ли ELB в режиме TCP по-другому? –

+0

@Michael: да, это немного отличается в этой конфигурации. SSL: 443 -> TCP: 8080 (что не подходит для нашего приложения, потому что оно не поддерживает сессионную липкость). На основе монитора IpTraf TCP-соединение от ELB к экземпляру получает CLOSED, но TCP-соединение из экземпляра с ELB остается открытым и потоковым. –

ответ

0

У нас была такая же проблема (но в .NET с IIS). Мы, похоже, решили это, переключившись с классического ELB на приложение ELB. Теперь запись в выходной поток закрытого соединения дает исключение, где вначале (на классическом ELB) этого не произошло.

Надеюсь, это поможет любому, кто работает в этой же задаче

Смежные вопросы