BiTel

Есть сервис со статическим адресом и стартом по трафику. На корневом устройстве Access+Accounting выставлен параметр connection.close.timeout=180 (распространяется на все подчиненные, посмотрел в конфиге). Однако когда трафик прекращается - в текущих сессиях видно что в поле Активность значение замирает, но сессия продолжает висеть и висеть. Больше часа висит - явно уже ненормально.

За это наверняка отвечает один из воркеров.
Настраивали параметры "accounting.worker" ?
Какая версия?

Версия 6.0 от 23.08.13. воркеры прописаны все, кроме serv.tracking. Судя по документации это

В логах вижу мелькает c периодичностью accounting.worker.3.finishing.1.delay=15

Из них одна (call которая) - это DHCP-сессия - завершается нормально по таймауту этим самым SessionFinishManager`ом при отключении компа, а вот 2 штуки auto так и продолжают висеть. Причём привязаны все сервисы к одному устройству, а следовательно имеют одинаковые таймауты закрытия.

Покажите конфиг для finishing

Вот так в общем. Таймауты уменьшил. Если посмотреть Текущую конфигурацию в устройстве, к которому привязан сервис - там это всё наследуется. Рестарт AA-серверов делал на всякий случай.

Уже скоро 4 часа как висят.

Посмотрел у себя - та же самая ситуация:




Сервер: вер. 5.2 сборка 1526 от 23.07.2013 15:29:29
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_22
inet вер. 5.2 сборка 1213 от 24.07.2013 15:33:55

А вот еще интересная картинка получилась - началась сегодня, закончилась вчера (их тоже 6, как и сплитнутых. просто 2 на др. странице). Я как то давно писал про это вот тут http://forum.bitel.ru/viewtopic.php?f=44&t=7357#p57746, что на границе суток таймаут получается если - то выходит такая хрень, но так и не пофиксили. Тут надо проверочку делать что если время "Активность" меньше "Начало", то и не надо её скидывать, т.к. это сплитнутая неактивная сессия как в данном случае.

Кстати, нашел я в логах финиширование этих сессий произошло в 02:28:41, т.е. таймаут получился 3 часа ровно.

+1 тоже самое наблюдаю

Разработчики ушли в себя.
Амир, как обычно, в пятницу выкатит очередную вундервафлю

Чёй-то нифига не выкатили... Это, конечно, не мегакритичный баг и у абонентов при таком раскладе будет всё работать, но как минимум будут возникать вопросы что это за сессии такие. Может уже исправите ? (вопрос к разработчикам)

В одном из апдейтов для автосессий сделали, что connection.close.timeout становится минимум 3-часа.
Сделали, из-за того, что у одного клиента стояло маленькое значение и создался миллион сессий при небольшое кол-ве абонентов с такой схемой.
Думаю, что действительно перестраховались. Но минимум нужно оставить, но какой? 1 час?

Так это же настраиваемый параметр. Этому абоненту можно было в конфиге то просто поставить connection.close.timeout=10800 и всех делов, а не так жестко сразу для всех кому надо и не надо. К тому же для отладки ждать этот самый минимум не очень удобно. Вот уж не знаю, нужно ли делать этот минимум или нет, этакая защита от дурака чтоли ? Я понимаю что порой Биллинг настраивают далеко не профессионалы, но в этом случае вашей ответственности за 1млн сессий не вижу.

И про второй момент где на последнем скрине пустая сессия началась сегодня и закончилась вчера не забудьте. Явный косяк.

Так что, может сделать минимум в 5 минут, а там уже каждый для себя пусть выставляет сколько надо. А то ведь как получается - большем минимума кто хочет поставит, а вот меньше - уже нет.

Может лучше проверять длительность сессии? Ну т.е. завершать трафиковые сессии, только если их длительность больше определённого значения из конфига. Т.о. мы зададим минимальную длину для трафиковой сессии.

Это не лучше, это дополнение. Например ставим минимум для таких сессий - 1 час. Вот качает юзер трафик 2 часа и потом прекращается. Через сколько нужно закрыть эту сессию ? Правильно, через connection.close.timeout секунд.

Но в любом случае идея заслуживает реализации, 2 параметра лучше чем один. Так мы не будем плодить короткие сессии и сильно долго ждать завершения длинных. В самом биллинге зашить дефолтные параметры (оба) в 1 час, минимум - 1 минута, чтобы всё-таки была возможность произвольного задания значений, а не перестраховываться за администраторов биллинга, что они что-то там выставили не оптимально - это был их выбор. А то ведь тут можно и базу грохнуть и сказать что у Битела нету защиты от случайного удаления базы биллинга.

Что-нибудь уже подскажите идёт ли процесс и в каком направлении.

Вижу апдейт с нужными фиксами. Большое спасибо, будем пробовать!

Все таки напрашивается еще параметр connection.auto.close.timeout. Ситуация - сервисы типа DynamicDHCP и StaticIP привязываются к одним и тем же коммутаторам, таймауты завершения нужны разные. Добавьте, пожалуйста. По дефолту равным connection.close.timeout сделать.

UP! Добавьте, плиз. Все-таки у автосессий логика другая немного и таймауты там разные нужно ставить.

Еще разок Up! Ну нелогично для принципиально разных типов сессий делать одинаковый параметр (и значение) таймаута.

Не работает параметр. Все равно завершается по connection.auto.timeout.

Выкладывается обновление.

Уже? Не? Что-то не видно в chanhelog исправления

6.0 же?

а, да, в модуле увидел. просто смотрел чейнжлог про сервер. непонятно, что-то есть там про Инет, что-то нету. попробуем.