Не уверен, что понимаю, почему мой сервер получает события "channelInterestChanged" в декодере кадра - PullRequest
Новая
       32

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

1 голос
/ 15 марта 2012

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

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

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

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

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

Спасибо.

1 Ответ

0 голосов
/ 17 марта 2012

Когда DownStreamChannelStateEvent запускается из обработчика (например, вызывая channel.setReadable(), channel.setWriteable()), событие изменит интересующую опцию клавиши селектора nio канала в NioDatagramWorker, позже UpstreamChannelStateEvent будет запущено с измененным опция (т.е. OP_READ или OP_NONE)

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

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

...