Проблемка
В методе InvokeBase файла VkApi.cs есть реализация механизма контроля частоты запросов к vk api, использование которой совместно с LongPoll'ом(или любом другом продолжительном запросе) приводит к проблеме, а именно:
В случае, если сгенерировать запрос к api, когда LongPoll уже ждет событий, то запрос не будет выполнен, пока LongPoll не получит любое событие, и не разблокирует _expireTimerLock. Таким образом, ожидая событие в течении 25 секунд(по-умолчанию), параллельно сгенерированное пользователем обращение к api зависнет на 25 секунд, прежде чем начать выполняться.
Решение 1:
Вынести SendRequest в место после lock{}, с целью укоротить неоправданно долгую блокировку _expireTimerLock
Перенести обновление LastInvokeTime из SendRequest в тело lock{}, с целью предотвратить race condition
Минус решения 1:
Выравнивание временных рамок будет работать корректно со стороны клиента, но возможна ситуация, когда запросы дойдут до сервера с опозданием, либо же все сразу. Такое возможно в случае, если произойдет сетевая задержка или лаг. В таком случае, мы рискуем исчерпать разрешенные запросы в секунду и сервер вернет ошибку.
Решение 2:
Реализовать какой-нибудь механизм, с помощью которого мы сможем держать заблокированным _expireTimerLock лишь до тех пор, пока мы гарантированно не передали серверу наш запрос(это нужно как-то отловить), ну или хотя бы гарантированно с ним не соединились. Таким образом мы делаем временные рамки более точными, обновляя LastInvokeTime только тогда, когда запрос уже дошел до сервера, Таким образом, мы побеждаем недостаток первого решения.
Предлагаю обсудить, как можно отловить факт соединения HttpClient с сервером/факт дохода запроса на сервер? Альтернативные решения приветствуются.
Проблемка В методе InvokeBase файла VkApi.cs есть реализация механизма контроля частоты запросов к vk api, использование которой совместно с LongPoll'ом(или любом другом продолжительном запросе) приводит к проблеме, а именно: В случае, если сгенерировать запрос к api, когда LongPoll уже ждет событий, то запрос не будет выполнен, пока LongPoll не получит любое событие, и не разблокирует _expireTimerLock. Таким образом, ожидая событие в течении 25 секунд(по-умолчанию), параллельно сгенерированное пользователем обращение к api зависнет на 25 секунд, прежде чем начать выполняться.
Решение 1:
Минус решения 1: Выравнивание временных рамок будет работать корректно со стороны клиента, но возможна ситуация, когда запросы дойдут до сервера с опозданием, либо же все сразу. Такое возможно в случае, если произойдет сетевая задержка или лаг. В таком случае, мы рискуем исчерпать разрешенные запросы в секунду и сервер вернет ошибку.
Решение 2:
Предлагаю обсудить, как можно отловить факт соединения HttpClient с сервером/факт дохода запроса на сервер? Альтернативные решения приветствуются.