Тайм-аут сокета в WSO2 ESB 5.0.0 - PullRequest
       4

Тайм-аут сокета в WSO2 ESB 5.0.0

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

Мы постоянно получаем время ожидания сокета в наших 2 экземплярах ESB, которые находятся в одном кластере.IP-адрес, который печатается в журналах, принадлежит Балансировщику нагрузки, который расположен поверх двух экземпляров ESB.Через некоторое время экземпляры ES перейдут в неработоспособное состояние и не будут обслуживать какие-либо запросы.

Ниже приведен образец журнала для справки.

TID: [-1] [] [2018-10-07 22: 42: 11,711] WARN {org.apache.synapse.transport.passthru.SourceHandler} - истекло время соединения после запросапрочитайте: http-input-5709 Время ожидания сокета: 180000 Remote Address: /10.246.19.23:45278

Пожалуйста, сообщите нам, если кто-нибудь сталкивался с подобными проблемами.

Ответы [ 2 ]

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

Наконец-то мы выяснили, в чем проблема.Время ожидания сокета приходило в наши журналы ESB из-за сбоя одного из API, и он не возвращал ответ вызывающему клиенту (даже ответ о сбое), поэтому в этом случае может быть поток, который будет удерживать этот единственныйтранзакция, которую он также будет ждать.Через некоторое время не будет доступных новых потоков для обслуживания запроса, поскольку этот сервер находился в неработоспособном состоянии.

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

TID: [-1] [] [2018-10-07 22: 42: 11,711] WARN {org.apache.synapse.transport.passthru.SourceHandler} - время ожидания соединения после прочтения запроса: http-incoming-5709 Время ожидания сокета: 180000 Удаленный адрес: /10.246.19.23:45278

Причиной вышеуказанной ошибки является то, что соединение от ESB к бэкэнду занимает более 180 000 миллисекунд, а ESB отмечает соединениекак истекло время ожидания.Я полагаю, что вы настроили время ожидания конечной точки на 180 000 миллисекунд.Это может происходить из-за медленного бэкэнда и того, что возврат ответа более 3 минут обычно не является хорошим признаком, что может привести к высокому использованию потоков в ESB.

...