BiTel

Решили вот Inet в продакшн выводить. Завели кучу девайсов, давим "Перечитать конфигурацию на серверах", в логах мелькают

такие сообщения для каждого свича и потом


Дальше Access перестает обрабатывать запросы и всё встаёт колом


access_status показыват

если Перечитать конфигурацию на серверах, становится Active: 230, ну а еще раз нажать - становится 300 и вываливается по вышеописанному сценарию.

Какие у вас класссы - ServiceActivator-ы?
Самописные? Скорее всего, для каждого коммутатора свой коннекшн заводится.

Коннекшн заводится в активаторе родительского устройства. Для коммутаторов используется немного модифицированный SnmpServiceActivator без получения коннекшинов.

Нашел зацепку, но все равно непонятно. Перекликается с темой про фейковые коннекшины. Оказывает, при перечитывании конфигурации родительское устройство свичей Shaper (есть еще DHCP Relay, но он не в счет, он без SA) проходит N+1 раз инициализацию (где N - кол-во дочерних свичей, видел в логах вагон сообщений INIT/DESTROY SA-родителя), а там в функции init используется this.con = Setup.getSetup().getDBConnectionFromPool(); Вот это и сжирает коннекшины. Ну да ладно, думаю получение коннекта к базе и его закрытие будет логичней перенести в функции connect/disconnect (или как лучше ?), но опять же остается вопрос - нафига 100500+1 раз инициализировать родительское устройство? Если я перенесу получение/освобождение ДБ-коннектов в connect/disconnect, но их выжрут фейковые подключения из соседнего топика http://forum.bitel.ru/viewtopic.php?f=44&t=8644

UP!

Сделали получение соединения в connect() и его возвращение в disconnect()?
init() и destroy() для парсинга конфигурации и освобождения других ресурсов, которые можно держать постоянно.

Если бы с подключениями из соседнего топика действительно была глобальная проблема, то давно бы исправили. И писали бы об этой проблеме не только Вы.

да, сделал в connect/disconnect. Просто в основном у многих схема с RADIUS, где подключения как такового нету, поэтому и не выражается это ЯВНО. Либо девайсов немного. Спасибо за разъяснения. init/destroy не столь принципиально что массово вызываются.

Там сейчас работает 100-200 потоков (sa.thread.count=), т.е. если использовать connect-disconnect, то будет открыто не более 100-200 соединений.
Если же использовать в init-destroy, то столько, сколько устройств, а при перечитывании конфигурации какое-то время в два раза больше.

Если получение соединения используется не только в Shaper, а не дополнительно и в Switch - в этом случае, соответственно, 200-400 - но это можно исправить, если получать соединение, привязанное к потоку: У этого соединения autoCommit=false - commit вызывается после обработки всей цепочки устройств, если не произошло ошибок. Или можно самому вызывать con.commit(); Закрывать это соединение не нужно.