Z5R-WEB + JSON (сервер не успевает ответить на события)

[Егор]

Здравствуйте!
Уже не первый день сталкиваемся с проблемой:
На какое-то время по какой-то причине контроллер теряет связь с сервером.
После восстановления связи они начинают стандартный обмен REQUEST - ANSWER, но не успевает сервер прислать Success, как контроллер шлет пакет EVENT-ов.
При этом контроллер отсылает эвенты ежесекундно, не смотря на то, что период опроса установлен в 5 секунд.
Сервер просто не успевает ответить.
"fw":"3.26"
"conn_fw":"1.0.130"

В итоге вся система залипает.
Единственно, что помогает - это перейти в GL, куда контроллер сольёт все свои эвенты, потом снова переводить в WEBJSON и перезаписывать 8000 карт.

Что с этим можно сделать?

[Егор]

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

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

[astashov]

Мне кажется не правильно, если решение от сервера по любому вопросу будет идти долго. Не забывайте, запросы синхронные, и пока "Вы" думаете, все остальные отдыхают.
Оптимизируйте и подстраивайте серверную часть. И да, контроллер в принципе может долго ждать. В одном из моих топиков есть дамп, где контроллер минуту ждал ответа от сервера. А это очень дофига....

[Егор]

Проблема в том, что контроллер ждёт где-то 15 секунд, после чего шлёт повторный запрос.
А ответ от сервера, у нас максимально 19 секунд. Это если контроллер пачку событий одним пакетом прислал.
Т.е. к тому моменту, как сервер отправит подтверждение, контроллер уже повторит запрос.

[astashov]

https://forum.ironlogic.ru/index.php?topic=933.30
Может тут что то для себя увидите. А вообще, поиск рулит.

[murat351]

Проблема оказалась в необходимости нашего сервера разбирать весь REQUEST и последовательно отвечать на него.
- не очень понятна проблема
после SET_ACTIVE  контроллер в пакете может прислать всего два сообщения CHECK_ACCESS - если контроллер в онлайне
 и EVENTS
ответ на  EVENTS - сохранить массив сообщений, посчитать их и сразу отправить ответ с количеством полученных строк
собственно разбором можно заняться после ответа.
При этом на пакет запрос - можно отправить пакет ответ

[Егор]

https://forum.ironlogic.ru/index.php?topic=933.30
Может тут что то для себя увидите. А вообще, поиск рулит.

Для себя в этой теме ответа не нашел, а так как статус [РЕШЕНО], то решил не возобновлять.

Проблема оказалась в необходимости нашего сервера разбирать весь REQUEST и последовательно отвечать на него.
- не очень понятна проблема
после SET_ACTIVE  контроллер в пакете может прислать всего два сообщения CHECK_ACCESS - если контроллер в онлайне
 и EVENTS
ответ на  EVENTS - сохранить массив сообщений, посчитать их и сразу отправить ответ с количеством полученных строк
собственно разбором можно заняться после ответа.
При этом на пакет запрос - можно отправить пакет ответ

Да, совершенно верно.
Исправили проблему, перенастроив сервер.

Но вот иметь возможность устанавливать для контроллера максимальное время ожидания от севера было бы очень полезно.
Уважаемый Мурат в вышеуказанной теме сам об этом говорит.
Не смотрели, можно ли это реализовать?

[astashov]

Для себя в этой теме ответа не нашел, а так как статус [РЕШЕНО], то решил не возобновлять.

В этой теме говорится о том, что контроллер работает в синхронном режиме, и пока контроллер не научится работать в асинхронном режиме, то задерживать его работу "ожиданиями" противопоказано. Т.е. пока контроллер ждет, другие события выполняться не будут.

Если не нашли, ну что-ж. Значит я Вас не понял. А вообще, просто хотел показать Вам, что долгие ожидания для контроллера вредны, и надо их убирать в фон. Вот и все. Собственно об этом же Вам написал murat. Видимо сложная параллель.