| forum.bitel.ru http://forum.bitel.ru/ |
|
| Быстрота вызова serviceModify после изменения договора http://forum.bitel.ru/viewtopic.php?f=44&t=7534 |
Страница 1 из 1 |
| Автор: | aiwbend [ 14 дек 2012, 09:37 ] |
| Заголовок сообщения: | Быстрота вызова serviceModify после изменения договора |
Сейчас если к примеру на договоре меняется его статус или тарифный план, serviceModify вызывается примерно через минуту. Было время когда он вызывался моментально, те например изменение статуса 12:23:33 после этого сразу вызывался serviceModify и создание новой сессии 12:23:34. Сейчас же выглядит примерно так - Изменение статуса 12:23:33, и новая сессия после serviceModify 12:24:20 Нам сейчас чтобы сразу получить результат и не ждать минуту, приходится пере сохранять сервис руками для вызова serviceModify. По какой причине может быть такое запоздание? |
|
| Автор: | Amir [ 14 дек 2012, 14:13 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
Нужно посмотреть, как быстро после изменения статуса договора в логах сервера появляется строка 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, мало или довольно быстро уменшаться). Бывает так что после тестовой конфигурации или изменения конфигурации устройств остаются события в очереди, которые уже никому не нужны. Возможно наоборот, по какой-то причине не успевает обрабатывать события быстро. |
|
| Автор: | aiwbend [ 14 дек 2012, 16:00 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
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. Что посоветуете? |
|
| Автор: | aiwbend [ 17 дек 2012, 10:53 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
В отчаянии удалил .../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 |
|
| Автор: | Amir [ 17 дек 2012, 14:11 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
Сколько активных сессий, какая конфигурация устройства (Access+)Accounting? |
|
| Автор: | aiwbend [ 17 дек 2012, 21:43 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
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 |
|
| Автор: | Amir [ 18 дек 2012, 00:13 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
Тогда совсем не понятно... Может быть время расходится на серверах? Все java приложения запускаются с последних билдов JDK? В том числе activeMQ? Еще можно посмотреть, логи Access, что там происходит; как быстро проходит событие InetSaStateModify в web-консоли activeMQ. Как быстро добавляется в счетчик Pending, как быстро переходит в Dequeued. |
|
| Автор: | Amir [ 19 дек 2012, 14:59 ] |
| Заголовок сообщения: | Re: Быстрота вызова serviceModify после изменения договора |
Обычно ожидание (по умолчанию минута) происходит после ошибки при вызове service(connection)Modify/Close, таковая тогда должна быть в логах Access. |
|
| Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|