I am currently maintaining a SNMP Manager application that uses SNMP++ (v3.4.2) that I am having some issues with. The SNMP Manager is currently set up to create a separate thread for each SNMP V3 agent that the manager application is configured to monitor. Each monitored-agent thread has its own Snmp object that the thread uses to send GET requests at regular intervals to verify that the agent is still up and functioning.
The original developer that wrote the SNMP v3 agent monitoring portion of the application placed a static thread guard that is shared by all SNMP v3 monitored-agent threads that allows only 1 thread to send a GET request at a time. The thread guard is not released until the agent responds to the GET request or a timeout occurs (timeouts are either 4 or 11 seconds). This was not a significant issue for us when the number of monitored SNMP v3 agents was small but we recently increased the number of SNMP v3 agents being monitored by more than double.
I think the original developer was attempting to protect the static instances of v3MP and USM classes referenced by the various monitored-agent threads.
Can you give any guidance as to whether or not it is thread safe to have multiple Snmp objects performing GET requests at the same time on separate threads (specifically in regards to the v3MP and USM classes)? Can I safely remove the static thread guard that is shared between all monitored SNMP v3 agent threads? Do I need to have the static thread guard in place only during engine id and USM discovery?
If the application architecture is completely undesirable, do you have any suggestions on how I might re-write the application? Should I have only a single Snmp object for the entire manager application and use asynchronous function calls?
Thanks in advance for the help and guidance.