Непонятно, почему мой сервер получает события «channelInterestChanged» в декодере кадров

Question

Я реализовал свой собственный декодер кадров для анализа байтов, полученных через сокет UDP (используя NioDatagramChannelFactory и ConnectionlessBootstrap) в соответствии с нашим протоколом. Чтобы следить за тем, что происходит на сервере при получении сообщений, я добавил журналы трассировки в каждый метод обратного вызова декодера.

Похоже, что почти для каждого сообщения, которое получает сервер, мы видим, что событие «channelInterestChanged» принимается дважды в методе channelInterestChanged(). Значение события сначала 0 (OP_NONE), затем 1 (OP_READ).

Я прочитал документацию об этом, но я все еще не уверен, почему я получаю такие события. Сначала я понял, что буфер приема (или очередь выбора) был заполнен, но сервер получает это событие столько же раз, сколько получает событие «messageReceived» (до вызова метода decode()), и все сообщения/frames должным образом декодируются, как ожидалось. Когда сообщения отсутствуют, я вообще не вижу никакого события. В этом случае, вероятно, это потому, что буфер приема сокета датаграммы заполнен. Но даже если я увеличиваю этот буфер приема, я продолжаю видеть эти события и пропускать сообщения.

Итак, мне интересно, почему для каждого полученного сообщения сервер также получает два «channelInterestChanged», один с значением OP_NONE и один с значением OP_READ. Пожалуйста, также обратите внимание, что в канальном конвейере после моего декодера кадров есть ExecutionHandler и другой бизнес-обработчик (который отправляет JMS-сообщение в экземпляр ActiveMQ).

Любая идея или объяснение для меня?

спасибо.

Answer 1

Когда DownStreamChannelStateEvent выстрела из обработчика (например, вызов channel.setReadable(), channel.setWriteable()), событие изменит заинтересованный вариант NiO кнопки выбора канала находится в NioDatagramWorker, спустя UpstreamChannelStateEvent уволят с измененным вариантом (т.е. OP_READ или OP_NONE)

Ваш кадр обработчик декодер принимает UpstreamChannelStateEvents потому, что некоторые другие обработчики в трубопроводе меняются параметры чтения интерес в этом канале (цели вызова channel.setReadable/setWriteable является дросселирования чтения/записи, чтобы избежать заторов, OutOfMemoryError в приложении).

Если у вас есть MemoryAwareThreadPoolExecutor в вашем конвейере (который контролирует размер используемой памяти канала), он может приостановить или возобновить чтение, вызвав channel.setReadable() в любое время, если канал получает сообщения слишком быстро. Возможно, вам придется сконфигурировать экземпляр MATPE с оптимальным maxChannelMemorySize, maxTotalMemorySize или отключить его, установив его на 0.