[SNMP4J] Strange problem with multithreaded SNMPv3-Scan

[Frank Fock]

Chris,

Removing the USM from the *singleton* SecurityModels affects
concurrently running threads, because the SecurityModels instance
is shared between them (at least as you implemented it - this is not
a requirement by SNMP4J).

Rather than creating new Snmp instances for each thread, I would
share a single instance or create the Snmp instances for each thread
before the threads are started.

If you are getting notInTimeWindow errors, then there might be also
two or more agents with the same engineID in your network.

Best regards,
Frank

chk-world at gmx.de wrote:

>Hi again,
>
>and thanks for your help (though it didn't helped me).
>As allready mentioned I increased the buffer size. Also I changed the close
>function. Now only snmp.close() is performed.
>
>Also I checked under windows 2000 with the same code than under Linux with
>the same effect. If there are more than 4 threads doing a synchronous send I
>get sometimes null as response on reqests that do  work when working with
>less threads. Also in some cases I get "NotInTimeWindow" or
>"usmStatsWrongDigests". This makes me thinking about what could be wrong all
>the time. But I'm doing nothing more than a simple GET.
>
>  
>
>>What could be the problem cause is your implementation
>>of the "close()" function. It removes the security model
>>USM from the security models. Since the close method
>>is run concurrently, you remove the USM while other
>>requests are still outstanding. The response cannot be
>>decoded then (if it is a SNMPv3 request).
>>    
>>
>
>Btw.: When I do SecurityModels.getInstance().addSecurityModel(usm); why not
>doing
>SecurityModels.getInstance().removeSecurityModel(new
>Integer32(usm.getID())); after the response is back with null or something
>else?
>
>Any more ideas? I could also provide you with a complete example if you
>want.
>
>Best regards
>Chris
>
>  
>