IronLogic СКУД
Сетевые контроллеры => Z5R WEB => Тема начата: Егор от 31 Октября 2018, 13:06
-
Здравствуйте!
Уже не первый день сталкиваемся с проблемой:
На какое-то время по какой-то причине контроллер теряет связь с сервером.
После восстановления связи они начинают стандартный обмен REQUEST - ANSWER, но не успевает сервер прислать Success, как контроллер шлет пакет EVENT-ов.
При этом контроллер отсылает эвенты ежесекундно, не смотря на то, что период опроса установлен в 5 секунд.
Сервер просто не успевает ответить.
"fw":"3.26"
"conn_fw":"1.0.130"
В итоге вся система залипает.
Единственно, что помогает - это перейти в GL, куда контроллер сольёт все свои эвенты, потом снова переводить в WEBJSON и перезаписывать 8000 карт.
Что с этим можно сделать?
-
Ответа пока нет, но мы попробовали разобраться своими силами.
Проблема оказалась в необходимости нашего сервера разбирать весь REQUEST и последовательно отвечать на него.
Будем придумывать какую-то промежуточную базу или файл, в который будет сбрасываться весь запрос для дальнейшего разбора, а контроллеру отвечать незамедлительно.
На самом деле нам бы очень помогло, если бы мы могли контролировать, сколько времени контроллер ждёт ответа от сервера, прежде чем слать повторный запрос.
-
Мне кажется не правильно, если решение от сервера по любому вопросу будет идти долго. Не забывайте, запросы синхронные, и пока "Вы" думаете, все остальные отдыхают.
Оптимизируйте и подстраивайте серверную часть. И да, контроллер в принципе может долго ждать. В одном из моих топиков есть дамп, где контроллер минуту ждал ответа от сервера. А это очень дофига....
-
Проблема в том, что контроллер ждёт где-то 15 секунд, после чего шлёт повторный запрос.
А ответ от сервера, у нас максимально 19 секунд. Это если контроллер пачку событий одним пакетом прислал.
Т.е. к тому моменту, как сервер отправит подтверждение, контроллер уже повторит запрос.
-
https://forum.ironlogic.ru/index.php?topic=933.30
Может тут что то для себя увидите. А вообще, поиск рулит.
-
Проблема оказалась в необходимости нашего сервера разбирать весь REQUEST и последовательно отвечать на него.
- не очень понятна проблема
после SET_ACTIVE контроллер в пакете может прислать всего два сообщения CHECK_ACCESS - если контроллер в онлайне
и EVENTS
ответ на EVENTS - сохранить массив сообщений, посчитать их и сразу отправить ответ с количеством полученных строк
собственно разбором можно заняться после ответа.
При этом на пакет запрос - можно отправить пакет ответ
-
https://forum.ironlogic.ru/index.php?topic=933.30
Может тут что то для себя увидите. А вообще, поиск рулит.
Для себя в этой теме ответа не нашел, а так как статус [РЕШЕНО], то решил не возобновлять.
Проблема оказалась в необходимости нашего сервера разбирать весь REQUEST и последовательно отвечать на него.
- не очень понятна проблема
после SET_ACTIVE контроллер в пакете может прислать всего два сообщения CHECK_ACCESS - если контроллер в онлайне
и EVENTS
ответ на EVENTS - сохранить массив сообщений, посчитать их и сразу отправить ответ с количеством полученных строк
собственно разбором можно заняться после ответа.
При этом на пакет запрос - можно отправить пакет ответ
Да, совершенно верно.
Исправили проблему, перенастроив сервер.
Но вот иметь возможность устанавливать для контроллера максимальное время ожидания от севера было бы очень полезно.
Уважаемый Мурат в вышеуказанной теме сам об этом говорит.
Не смотрели, можно ли это реализовать?
-
Для себя в этой теме ответа не нашел, а так как статус [РЕШЕНО], то решил не возобновлять.
В этой теме говорится о том, что контроллер работает в синхронном режиме, и пока контроллер не научится работать в асинхронном режиме, то задерживать его работу "ожиданиями" противопоказано. Т.е. пока контроллер ждет, другие события выполняться не будут.
Если не нашли, ну что-ж. Значит я Вас не понял. А вообще, просто хотел показать Вам, что долгие ожидания для контроллера вредны, и надо их убирать в фон. Вот и все. Собственно об этом же Вам написал murat. Видимо сложная параллель.