BiTel

Снова как всегда в праздник или в выходной ...
Такая проблема
Вдруг собственно начались проблемы
до сего дня работало ... сейчас у части абонентов постоянно рвется сессия ...
в activemq очередь сообщений растет сброс не помогает
помогите разобраться нужно срочно

пробовали вот это http://wiki.bitel.ru/index.php/Inet_FAQ ... 0.B8.D1.8F

и в логах accounting и access есть ошибки?

Ошибок в логах нет
Очередь очищал ... копится снова

accounting и access рестартили? какие версии? Перечитать конфигурацию на устройствах пробовали?

версии последние рестартил кучу раз ... все тоже самое

после очистки очереди приложения ребутили? сесии не дублируются у проблемных клиентов?

попробуйте дин код перекомпелировать, accounting и access сделать еще раз update, посмотреть на нас запросы от биллинга приходят или нет, ну и время глянуть может чего пошло нетак

ребутили

update делал, дин код компилировал

пробовать вот так,
2. Уменьшить в конфигурации устройства connection.close.timeout и connection.suspend.timeout до минуты или даже 5 секунд, указать в конфигурации корневого устройства более частую попытку завершения сессии http://bgbilling.ru/v6.1/doc/ch17s07s01.html:

# пауза между заданиями
accounting.worker.3.finishing.1.delay=10
# максимальное количество сброшенных соединений в базу за задание
accounting.worker.3.finishing.1.batchSize=1000.

Перезапустить InetAccounting, затем после того как сессии будут завершены в биллинге и пропадут из монитора вернуть правильные значения connection.close.timeout и connection.suspend.timeout и нажать "Перечитать конфигурацию на серверах". Позже можно вернуть сброс сессий в БД (finishing) в прежние значения (для этого понадобится перезапуск InetAccounting).

появились ошибки в Access
InetSaStateModifyEvent - Connection not found with id= ...

у вас уже была в мае эта проблема видимо не решилась, в тот раз решили установкой radius.servSearchMode=1 в конфиге SE100

проверьте
Что в inet-access.xml в параметре
Код:
<!-- типы фейковых устройств, являющихся аккаунтинг серверами -->
<param name="accounting.deviceTypeIds" value=""/>
?
Должен быть id типа устройства Access+Accounting

с тех пор работало ... не работает с сегодняшнего утра

проверьте все ровно, еще посмотрите лог ацесс после нажатия синхронизировать

Там все верно

connection.suspend.timeout=
connection.close.timeout=
какие у вас значения?

960
1200

как и было

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

Начнем с сути - что значит "рвется сессия" ??? Она у него прямо рвется или только в биллинге ? Снова предоставляется мало информации и тред превращается в пустую переписку. Уже чтоли описали бы подробно схему да конфиги бы все повыкладывали - давно бы вам рекомендации дали по улучшению стабильности работы.

В последнем билде для 6.0 беда с сессиями. Нам помогло откатиться на сборку от 20.10.2014
Правда у нас это по другому проявлялось, без видимых причин не проходила авторизация по IP, код ошибки [1]

Какие сообщения растут в activemq ? Включить web-интерфейс, как описано тут

И посмотрите какие сообщения скапливаются в очереди.

что значит рвется ? Дайте доступ посмотреть.

есть подобная ситуация

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Судя по этом скриншоту ничего не скапливается. первый столбец у вас по нулям.

ну да не туда посмотрел ... на 3 -й 4-й ...

а с вот с этим как бороться ... а то народ нормально пользоваться не может ...

По множеству сессий - 02.11 добавили проверку, чтобы в DHCP-запросе поле Requested IP Address совпадало с тем что должны выдать.
Боролись с роутером JWNR2000v2, который параллельно несколько транзакций получения IP-адреса ведет.
Только проверка стала работать и на DISCOVER-запросах, что не корректно.
Т.е. если клиент слал DISCOVER с каким-то левым IP-адресом в Requested IP Address - ему ничего не предлагали.

Это все про InetDhcpHelperProcessor.

Выложили обновление.