После обновления до snm4j.2.6.3 с snmp4j.2.5.8 я столкнулся с новой проблемой. Ловушки иногда не прослушиваются после старта приложения

После обновления до snm4j.2.6.3 с snmp4j.2.5.8 я столкнулся с новой проблемой. Ловушки иногда не прослушиваются после запуска приложения, после перезапуска приложения ловушки прослушиваются как обычно. Во время этой проблемы ловушки принимаются через порт 162 (процесс получения ловушек) на клиентском сервере, но не принимаются переопределенным методом «processPdu» интерфейса «CommandResponderEvent» snmp4j. Тот же фрагмент кода отлично работал с snmp4j.2.5.8 без каких-либо проблем.

Пробовал с более поздней версией snmp4j.2.7.0 и snmp4j.2.8.0, но сами ловушки не прослушиваются, но когда я использовал tcpdump для процесса приема ловушек, работающего на порту 162, ловушки поступают на клиентский сервер, но не прослушиваются snmp4j.

Примечание. Я использую MultithreadedMessageDispatcher.

Я хотел знать, сталкивался ли кто-нибудь с такой же проблемой с версиями snmp4j.2.6.3, snmp4j.2.7.0 и snmp4j.2.8.0, и как вы решили эту проблему?

Заранее спасибо!


person Anjana    schedule 25.10.2019    source источник


Ответы (1)


Когда эта проблема возникает, то есть когда ловушки не прослушиваются через некоторое время, я взял дамп потока Java с помощью команды jstack. Существует поток DEADLOCK ON 'DefaultUDPTransportMapping_0.0.0.0/162' org.snmp4j.transport.DefaultUdpTransportMapping, и некоторые потоки из пула потоков, созданного с использованием org.snmp4j.util.ThreadPool, находятся в состоянии "BLOCKED". Потоки, созданные для обработки ловушек, оставались в заблокированном состоянии без какой-либо дальнейшей обработки.

Я поделился приведенными выше подробностями с командой SNMP4J и получил подтверждение от Фрэнка Фока о том, что в классе SNMP4J 2.6.3 ThreadPool есть ошибка, которая была исправлена ​​в более поздней версии.

Надеюсь, это может помочь другим, кто использует версию SNMP4J 2.6.3 и сталкивается с той же проблемой.

person Anjana    schedule 27.11.2019