BiTel

При массовых обращениях к устройству типа manad, bgbilling сыпет периодически ошибку -

access 04-22/17:42:22 ERROR [dm-p-14-t-52] DeviceManageWorker - Check uptime error for device: 288: Connection reset. Waiting 60000 ms for next try.
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.lang.Thread.run(Thread.java:745)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)
-------------------------------------------------

Я существенно видоизменил perl manad-а(но это обстоятельство обнаруживается и на дефолтном скрипте), он выполняет ряд дополнительных функций, в частности делает рестарт dhcp сервера, при каждом изменении. полагаю, что причина сообщений в переполнении очереди коннектов с manad-ом. так как периодически он как бы залипает и перестаёт принимать запросы, через 3-5 минут - опять начинает.

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

может быть лучше как-то попробовать со стороны perl решить эту проблему ?

да это я полюбому буду делать, просто информирую, что есть такая засада.
не пойму правда в какое место смотреть.. думаю научить manad форкаться, а не на одном порту висеть..

а вас какое дерево устройств? под манадом что-то есть? абонент к самому манаду привязан ?

под манадом (в дереве) устройств нет.

про привязку каждого к манаду.. дерево сложное, для правильного распределения ip адресов операторами, которые в этом ничего не понимают - "устройствами" являются адреса домов(адрес прикручен через атрибуты), так можно привязать IP ресурс к адресу обслуживания. технология DOCSIS и дома объединены в группы, согласно топологии. manad привязан к такому "устройство-адресу" их действительно очень много (580...600), netflow собирает через flow.agent.link=8:-1 на корневом устройстве.