For some audit reason I was trying to implement an AuthenticationFailureListener. Our application has an internal MO Table and that MO Table can be get and set.
For testing purposes we are using snmpwalk, snmpbulkwalk linux command. These commands have some internal timeouts.
The below AuthenticationFailureListener is doing a sleep for the 5th query and for that snmpwalk timeout.
But any subsequent query also times out in my case. So this thread sleep practically killed the snmp4j subsystem. Well in practice it was not a sleep causing the issue but some long execution action.
One other important thing is that if you use snmpwalk -t 11 … then it is working fine. The 5th query is going through after waiting 10 seconds and subsequent queries are also working.But with the default value it kills the subsystem.
import lombok.extern.slf4j.Slf4j;
import org.snmp4j.event.AuthenticationFailureEvent;
import org.snmp4j.event.AuthenticationFailureListener;
import org.snmp4j.smi.Address;
@Slf4j
public class SnmpAuthenticationFailureListener implements AuthenticationFailureListener {
/**
* Running below command succeeds 4 times.
* Fails for 5th which is fine.
* But any subsequent try will also fail if connection is using tcp and no answer is provided ever.
* Looks like the 5th query kills the snmp4j subsystem.
* With udp, all request are working except the 5th.
*
* snmpkwalk -e $ENGINEID -E $ENGINEID -Pd -Pe -Pw -PW -On -Ou -v 3 -l authPriv -u $USER -n $CONTEXT -a MD5 -A $AUTH -x DES -X $PRIV tcp:localhost:1161 $MOTABLEOID
*
* Using snmpwalk -t 11 ... prevents killing the snmp4j subsystem
*
*/
Long counter = 0L;
@Override
public <A extends Address> void authenticationFailure(AuthenticationFailureEvent<A> event) {
try {
counter++;
log.warn("Counter {}", counter);
if (counter < 5) {
log.info("Working fine now");
}
if (counter == 5) {
log.warn("Let us sleep and kill it");
Thread.sleep(10000);
}
if (counter > 5) {
log.warn("This should work now but it does not?");
}
} catch (Exception e) {
e.printStackTrace();
}
}
}