Я реализовал свой собственный декодер кадров для анализа байтов, полученных через сокет UDP (используя NioDatagramChannelFactory и ConnectionlessBootstrap) в соответствии с нашим протоколом. Чтобы следить за тем, что происходит на сервере при получении сообщений, я добавил журналы трассировки в каждый метод обратного вызова декодера.Непонятно, почему мой сервер получает события «channelInterestChanged» в декодере кадров
Похоже, что почти для каждого сообщения, которое получает сервер, мы видим, что событие «channelInterestChanged» принимается дважды в методе channelInterestChanged(). Значение события сначала 0 (OP_NONE), затем 1 (OP_READ).
Я прочитал документацию об этом, но я все еще не уверен, почему я получаю такие события. Сначала я понял, что буфер приема (или очередь выбора) был заполнен, но сервер получает это событие столько же раз, сколько получает событие «messageReceived» (до вызова метода decode()), и все сообщения/frames должным образом декодируются, как ожидалось. Когда сообщения отсутствуют, я вообще не вижу никакого события. В этом случае, вероятно, это потому, что буфер приема сокета датаграммы заполнен. Но даже если я увеличиваю этот буфер приема, я продолжаю видеть эти события и пропускать сообщения.
Итак, мне интересно, почему для каждого полученного сообщения сервер также получает два «channelInterestChanged», один с значением OP_NONE и один с значением OP_READ. Пожалуйста, также обратите внимание, что в канальном конвейере после моего декодера кадров есть ExecutionHandler и другой бизнес-обработчик (который отправляет JMS-сообщение в экземпляр ActiveMQ).
Любая идея или объяснение для меня?
спасибо.
Было бы интересно узнать это самостоятельно. Почему бы вам не попробовать подключить источник Netty и отладить его, Netty использует метод fireEvent, который отправляет эти события вверх/вниз по каналу. Возможно, это происходит от java ** селектора NIO ** и Netty просто передает его вашему декодеру кадра. – Abe