BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 08 июл 2025, 05:33

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
СообщениеДобавлено: 14 дек 2012, 09:37 
Не в сети

Зарегистрирован: 20 апр 2011, 09:56
Сообщения: 346
Карма: 19
Сейчас если к примеру на договоре меняется его статус или тарифный план, serviceModify вызывается примерно через минуту. Было время когда он вызывался моментально, те например изменение статуса 12:23:33 после этого сразу вызывался serviceModify и создание новой сессии 12:23:34. Сейчас же выглядит примерно так - Изменение статуса 12:23:33, и новая сессия после serviceModify 12:24:20

Нам сейчас чтобы сразу получить результат и не ждать минуту, приходится пере сохранять сервис руками для вызова serviceModify.

По какой причине может быть такое запоздание?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 14 дек 2012, 14:13 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Нужно посмотреть, как быстро после изменения статуса договора в логах сервера появляется строка Process event cid ...; event Event[ru.bitel.bgbilling.kernel.event.events.ContractStatusChangedEvent... по этому cid.
Затем посмотреть в web-консоли activeMQ что приисходит с очередями (Queues), в особенности с очередями BG.Event.ru.bitel.bgbilling.kernel.event.events.ContractStatusChangedEvent и BG.Event.ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent, какие значения в Number Of Pending Messages (при нормальной работе должно быть 0, мало или довольно быстро уменшаться).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 14 дек 2012, 16:00 
Не в сети

Зарегистрирован: 20 апр 2011, 09:56
Сообщения: 346
Карма: 19
Amir писал(а):
Нужно посмотреть, как быстро после изменения статуса договора в логах сервера появляется строка Process event cid ...; event Event[ru.bitel.bgbilling.kernel.event.events.ContractStatusChangedEvent... по этому cid.

моментально

Amir писал(а):
Затем посмотреть в web-консоли activeMQ что приисходит с очередями (Queues), в особенности с очередями BG.Event.ru.bitel.bgbilling.kernel.event.events.ContractStatusChangedEvent и BG.Event.ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent, какие значения в Number Of Pending Messages (при нормальной работе должно быть 0, мало или довольно быстро уменшаться).

Цитата:
BG.Event.ru.bitel.bgbilling.kernel.event.events.ContractStatusChangedEvent
Number Of Pending Messages 0
Number Of Consumers 1
Messages Enqueued 25080
Messages Dequeued 25080

Цитата:
Name BG.Event.ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent
Number Of Pending Messages 0
Number Of Consumers 532
Messages Enqueued 11971
Messages Dequeued 11971

Number Of Consumers, ни в этом ли проблема, что это за потребители такие?
и везде Number Of Pending Messages 0.

Что посоветуете?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 дек 2012, 10:53 
Не в сети

Зарегистрирован: 20 апр 2011, 09:56
Сообщения: 346
Карма: 19
В отчаянии удалил .../data/kahadb, не помогло. Какие еще мб причины?


Сервер: вер. 5.2 сборка 1359 от 02.12.2012 16:15:29
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_31
inet вер. 5.2 сборка 1027 от 29.11.2012 19:15:37


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 дек 2012, 14:11 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Сколько активных сессий, какая конфигурация устройства (Access+)Accounting?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 дек 2012, 21:43 
Не в сети

Зарегистрирован: 20 апр 2011, 09:56
Сообщения: 346
Карма: 19
1 сервис - 1 сессия.

Цитата:
#типы устройств - Nas-ов
radius.deviceTypeIds=2
#типы устройств, являющиеся dhcp relay
#dhcp.relay.deviceTypeIds=1

#количество потоков на worker'а
accounting.worker.1.thread.count=1
#тарификатор:
#минимальная сумма трафика, при которой тарифицировать соединение
accounting.worker.1.tariffication.1.minDeltaAmount=0
#пауза между заданиями тарификации
accounting.worker.1.tariffication.1.delay=10
#максимальное количество тарифицируемых соединений за задание
accounting.worker.1.tariffication.1.batchSize=100
#трекер (обработка сессий без наработки):
#пауза между заданиями трекинга
accounting.worker.1.tracking.1.delay=20
#максимальное количество проверенных соединений за задание
accounting.worker.1.tracking.1.batchSize=100

#количество потоков на worker'а
accounting.worker.2.thread.count=1
#сброс в базу трафиков и наработки
#минимальная наработка, при которой сбрасывать соединения в базу
accounting.worker.2.flushing.1.minDeltaAccount=0
#пауза между заданиями сброса в базу
accounting.worker.2.flushing.1.delay=20
#максимальное количество сброшенных соединений в базу за задание
accounting.worker.2.flushing.1.batchSize=500

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

#таймаут перевода соединения в статус suspended при остутствии радиус пакетов
connection.suspend.timeout=900
#таймаут закрытия соединения при остутствии радиус пакетов (не складывается с connection.suspend.timeout)
connection.close.timeout=900
#таймаут перевода соединения в статус suspended при остутствии радиус пакетов (для сессий с ограниченным доступом)
#connection.disable.suspend.timeout=900
#таймаут закрытия соединения при остутствии радиус пакетов (не складывается с connection.suspend.timeout, для сессий с ограниченным доступом)
#connection.disable.close.timeout=900


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 18 дек 2012, 00:13 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Тогда совсем не понятно... Может быть время расходится на серверах?
Все java приложения запускаются с последних билдов JDK? В том числе activeMQ?

Еще можно посмотреть, логи Access, что там происходит; как быстро проходит событие InetSaStateModify в web-консоли activeMQ. Как быстро добавляется в счетчик Pending, как быстро переходит в Dequeued.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 19 дек 2012, 14:59 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Обычно ожидание (по умолчанию минута) происходит после ошибки при вызове service(connection)Modify/Close, таковая тогда должна быть в логах Access.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 8 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.048s | 33 Queries | GZIP : On ]