Мы работали над решением проблемы, которую мы имеем на сервере, на котором установлен обратный прокси-сервер apache (это должен быть apache).Я публикую это в надежде, что что-то выскочит, мы еще не думали проверить.
Это загрузочное приложение Spring, использующее шлюз Zuul перед микросервисами, и старое приложение Spring MVC, обновленное для работы с загрузочными библиотеками Spring.Когда происходит изменение в унаследованном приложении, маршрут вызывается для службы сущностей, и AMQ используется для отправки сообщения mqtt, сообщающего новому приложению, чтобы проверить состояние базы данных сервера MS SQL и обновить веб-дисплей, управляемый Ember.Все это проходит через 2 Apache обратных прокси.Первый из двух - это место, где возникают проблемы.
Client (C) -> Reverse Proxy 1 (RP1) -> Reverse Proxy 2(RP2) -> Service (S)
C: running on Ember.js framework, with ember-paho-mqtt library
Он отлично работает в локальном dev, но при развертывании на серверах промежуточной установки Windows приложение завершается ошибкой через несколько минут, а затем netstat показывает сбой close_waitНа сервере, на котором размещен обратный прокси-сервер apache, указано, что оно не исчезает.Мы считаем, что они следуют за сбоем, а не по его причине, но что-то может исчерпывать некоторый пул потоков, может быть, тот, который используется apache-подобными клиентами, пытающимися подключиться без необходимости?Но close_waits происходит, когда на сервер поступило сообщение о закрытии соединения, он завершил работу с любыми данными в процессе, но не получил ответа от клиента, говорящего ему о завершении работы, верно?
Веб-интерфейсы не работают, но существующие соединения продолжают работать при более непосредственном тестировании, и иногда система восстанавливается, а иногда нет.
Устаревшее приложение развернуто на JBoss, а микросервисы - на RedHat Tomcat.сервера.
Мы также используем облачный сервис Azure как часть сложного процесса авторизации oauth2.
Я работаю в команде и только периферийно участвую в проекте, главным образом в вышеупомянутом унаследованном приложении.Мы полагаем, что проблемы возникают, когда данные унаследованного приложения изменяются, и сообщение направляется микросервисам с весенней загрузкой, и что виновник так или иначе связан с веб-сокетами.Но мое понимание архитектуры более размытое, чем хотелось бы, извините за это.
У нас есть некоторые существующие теории.Пару лет назад я работал над сетевым приложением Netty в nix, и у меня была куча close_waits, которые я смог предотвратить, установив ограничения потоков в Java.AMQ использует Netty под капотом, поэтому одним из вариантов может быть обменять его и вставить вместо него RabbitMQ.Мы используем Paho для mqtt и тщательно изучили, как убедиться, что он закрывает соединения.Я также читал, что websockets.io может вызвать такие проблемы, и может помочь замена SockJS, которая проще.Мы попытались установить и отменить различные тайм-ауты / сообщения активности безуспешно.Мы читали, что есть ограничение потока на Apache, как мы, вероятно, настроили его, но его увеличение может усугубить ситуацию, рискуя трепетать от перестановки памяти.
Так что мы цепляемся за соломинку, иприветствовал бы любые пути спасения, брошенные нашим путем.Я сделаю все возможное, чтобы предоставить больше информации заинтересованным сторонам.