Hi,

You can use a single instance of SnmpTarget for contacting 'n' number of devices. However, if a pool of SnmpTargets are used then releaseResources() method should be called on every SnmpTarget instance and when this method is called on the final instance of SnmpTarget these will be garbage collected .

Regards,
Guyus.

> In a multi-threaded application would the cost of SnmpTarget creation justify pooling of SnmpTarget instances or should a request thread create and releaseResources on an SnmpTarget for every interaction with a device?

In our case, we found that by the time we reached dozens of instances, it paid off to make a pool. There seems to be significant overhead in the constructor.

Hi,

Can you please elaborate on this .

In our case, we found that by the time we reached dozens of instances, it paid off to make a pool. There seems to be significant overhead in the constructor.

Regards,
kcp

Can you please elaborate on this .

In our case, we found that by the time we reached dozens of instances, it paid off to make a pool. There seems to be significant overhead in the constructor.

Regards,
kcp

We made a naive manager that used a thread per agent and freely created "new SnmpTarget()" whenever it needed something from the Adventnet API. It worked fine for a few agents, but as the system scaled up, the performance became atrocious. There were many things to be fixed, most of our own doing, but one of the measurable improvements was to avoid constructing and collecting SnmpTarget() instances. Of course, you have to measure and profile each application, but in our case it clearly paid off to keep the SnmpTargets alive in a pool and keep reusing them, at least at the rate we were going through them.
A more thoughtful design probably would have either used the low-level API, or been more thrifty with SnmpTargets to begin with.