Хех, только было хотел создать такую же тему.
1. У нас похожая ситуация: биллинг получил 3 стоп-пакета и создал по ним 3 идентичных сессии. Но, в отличие от топикстартера, каждой сессии привязалась своя запись в таблице логов радиуса.
Кроме того, странно, что в первом посте у двух пакетов одинаковый Acct-Delay-Time.
У нас у трех сессий он, соответственно, 0, 3 и 6. Т.е. это счетчик повторных передач в секундах с первой попытки, если от радиуса не приходит ответа о получении.
Версия радиуса: version 5.0 build 177 from 16.03.2010 15:35:41
2. Хотел сделать выборку таких дублей запросом:
Код:
select h323_id, count(*) cnt from log_session_12_201007 group by h323_id having cnt>1;
Но по полю h323_id нет индекса. Добавьте пожалуйста, т.к. это поле явно предназначено для поиска.
3.
manowaretz писал(а):
в версии 5.0 в том же класссе и методе при обработке стоп пакета
найденная сессия из кеша не удаляется сразу.
Из кеша она уйдет только по истечению таймаута
if ((conStart != null) &&
((now - conStart.getTimeInMillis()) / 1000L > maxTime * 2))
{
conList.removeCon(nasCon);
}
прошу поправить эту ситуацию.
Как мне тут подсказывают, сессия не удаляется сразу умышленно, на случай если некоторые accounting-пакеты запоздают и придут после stop-пакета. Так что всё в порядке. А вот проверку стоп-пакетов по "h323-conf-id" было бы неплохо сделать, чтобы избежать таких дублей.
Итого:
- не добавлять повторные сессии в log_session с тем же h323_id хотя бы в течение часа (т.к. h323_id не обязательно уникальный, афаик)
- индекс по h323_id в log_session
Вход
Регистрация
FAQ
Поиск
