BiTel

Есть проблема.

Второй месяц подряд идут обращения из Т.П., по поводу не верного блокирования шлюза IPN, сервером. Шлюз блокируется, даже при положительном балансе.

Начисление абонплаты запускается в 05 мин. каждого часа.
Проверка шлюзов IPN запускается с интервалом в 5 мин.

Сервер 4.6.647
IPN 4.6.239

в логах шедулера надо искать строки типа :
Locking xxx balance: -188.38 limit 0.00
где xxx - номер договора

02-01/01:10:05 INFO [pool-2-thread-2] IPNTestGates - Locking XXX balance: -146.23 limit 0.00

Ув. разработчики, кто нибудь ответит?

у вас это стабильно происходит ? Попробуйте разнести подсчёт абонплаты и обсчет IPN по времени, чтобы они не пересекались . не получается это отловить

Предлагаю установить в на таблицу contract_balance подобие вот этого тригера :
http://wiki.bgbilling.ru/index.php/%D0% ... 0%B8%D0%B9

и отследить когда меняется баланс . Если ситуация повторится и баланс неожиданно временно станет отрицательыным, тогда нужны логи шедулера и сервера на момент этих изменений

Да регулярно, вчера ещё всплыли договоры с такой проблемой.
Триггер на таблицу contract_balance поставим, но придётся ждать следующего месяца.
Абоненты сидят без связи, пока сообразят обратится в ТП.

А почему ждать следующего месяца ? у вас в середине месяца такое не происходит ?

Ну по крайней мере ТП не обращалась с такой проблемой в середине месяца.

мы наткнулись еще на один такой случай ..там это произошло 31-го числа

Триггеры на добавление, изменение таблицы contract_balance стоят, посмотрим что происходит и когда.

Вот такое действие, сначала INSERT с вх. ост = 0, а потом UPDATE с вх.ост=1000 - нормальное поведение?

да

В продолжение темы. Поступил запрос из ТП, что при положительном балансе, шлюз не перешёл из состояния "заблокирован" в состояние "закрыт". Пришлось открывать в ручную.

Вот логи по этому договору, собранные триггером:

А это другой случай. Обратную операцию , т.е перевод из состояния открыт в состояние закрыт делает не задача проверки шлюзов . Это происходит только по приходу платежа . Но у вас приходов платежа не было . В 16:00:03 у вас уменьшилась наработка . Посмотрите какой пересчет был в это время и почему так получилось .

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

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

что вы понимаете под блокировкой и разблокировкой ?

блокировка - состояние шлюза "Заблокирован", абонент не может сам открыть.
разблокировка - состояние шлюза "Закрыт", абонент может сам открыть.

т.к открытие шлюза это и есть разблокировка ..вы просто разнесли эти понятия выше

Нет ..автоматически(в задаче проверки шлюзов) происходит только бликировка по состоянию баланса. Обратная операция не производится

т.е. состояния шлюза "Закрыт/Открыт" меняются только по событию прихода платежа?

И как быть в такой ситуации? Всем в ручную после выхода из минуса или скриптом по таймеру, не по приходу платежа, "разблокировать"?

не совсем . Работает так

1. задача поверки шлюзов запускается по планировщику и кроме проверки статус самих шлюзов (реальны статус шлюза на железке совпадает со статусом модуля IPN ) она перед этим еще может менять статус модуля IPN. Но меняет она его в одну сторону. Т.е если баланс стал меньше лимита , то стату шлюза меняет за заблокирован.

2. По приходу платежа(или изменения лимита ) если баланс стал больше лимита , то статус шлюза меняется на открыт.

Логика тут такая . наработка обычно должна расти в результате пересчетов, а не уменьшаться, поэтому в 1-м пункте статус IPN меняется только в одну сторону . И баланс должен расти только во 2-м случае . Если это происходит по каким-то другим причинам , то это либо ошибка и надо разбираться почему наработка уменьшилась либо это какой-то специальный случай (поменяли тариф и сделали перобсчет напрмер) и в этом случае надо поменять статус шлюза вручную.



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

вот тут эта тема поднималась уже:
viewtopic.php?f=7&t=3244

Шлюз не переходит из состояния "Заблокирован" в состояние "Открыт" по приходу платежа через модуль "карточки и удалённые платежи".
Если платёж внести из клиента, то статус меняется.

Сервер 5.0.768.

Есть сервер 5.0.766 на нём такой проблемы не наблюдается.

Обновил сервер до 5.0.778
Ситуация не изменилась, при приходе платежа шлюз IPN не меняет статус.
Сейчас вышел из положения путём ручного смены статуса в базе.

Так же не понятки со сменой статуса шлюза на "заблокирован" задачей IPNTestGates:



Лог scheduler.log:

Сегодня пришёл платёж от дилера и шлюз успешно сменил статус с "Заблокирован" на "Открыт".

Что происходит, от чего зависит результат? Куда копать, что смотреть?

в Locked clients: выводятс те, у кого сменился статус при запуске этой задачи . Т.е баланс меньше лимита, а статус открыт . тогда меняется статус в ipn_contract_status. У вас похоже таких нет.

статус договора у вас при этом какой ?