BiTel

Всем здравствуйте.

Имеем следующий набор
Клиент: вер. 5.1 сборка 544 от 14.06.2011 11:40:09
Сервер: вер. 5.1 сборка 665 от 14.06.2011 11:39:55
ipn вер. 5.1 сборка 237 от 26.05.2011 11:26:59
Шлюз написан на Java. Ходит на Cisco и посылает команды.

После обновления на сборку 237 для ipn и 665 для сервера стал замечать, что статус шлюза в БГ меняется, а вот сам шлюз некоторых моментах не отрабатывает.
При каких событиях не срабатывает шлюз:
- изменение лимита (приход платежа)
- изменение статуса договора (приостановлен .... )

Наш шлюз пишет лог кого, когда, какие команды отправлялись с помощью log4j. В этих случаях в логах ничего нет о работе шлюза и на оборудование команды не приходили.

Если ручками переключить шлюз - то все работает. Статус меняется, шлюз отрабатывает, команды уходят.

у вас задача проверки шлюзов запущена?

В сборке 235 поменяли
"Статус шлюза теперь не меняется синхронно при обработке смены статуса договора. Иначе обработчик событий подвисал, если подвисали шлюзы. "

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

Задача запущена.
Но Задача работает 1 раз в сутки и по выходным не работает.
О том, что статус шлюза меняется не синхронно - я прочитал, но не подумал, что задача проверки шлюзов восстанавливает справедливость.
На самом деле это очень неудобно и получается на статус шлюза нельзя положиться.
Необходимо пойти и проверить, а выполнился ли сам шлюз.
Перестроить расписание задачи проверки шлюзов - добавить нагрузку на оборудование.

Почему бы не задействовать в этом случае ActiveMQ и слать туда сообщение, чтобы асинхронно выполнился сам шлюз, а не ждать "задачи".

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

Странно, я когда прочитал про асинхронность, тоже подумал, что выполняется сразу, но отдельным тредом. Порадовался ещё тогда
А отдельным потоком нельзя сделать?

Присоединяюсь к вопросу.

Вам нужно бесконечное количество висящих потоков в сервере ? Это как бы не его задача . Этим занимается задача шедулера - она каждый шлюз запускает в отдельном потоке . Провисание шлюза может произойти из-за криво написанного скрипта , после этого перестанет работать сервер, перестанет обрабатывать события , от этого пытались уйти , так как надоела проблема в тех. поддержке - " у нас не обрабатываются события ". Можно и отдельным потоком в сервере, но боюсь тогда появится проблема - "сервер выбрал всю память" или что-то нибудь с потоками вылезет.

Не уточнил - в шедулере отдельным потоком естественно.

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

Выложил обновление , вернул все обратно .

И добавил параметр gate.contract.timeout - timeout работы шлюза, действующий при смене статуса шлюза для одного договора. при по умолчанию 1800000 ( 30 мин ).

а теперь откатил вообще все . Вернули по-старому

Обновились, проверили - ок.