[snmp] Need way to re-discover timeline info to recover from usmStatsNotInTimeWindows

[K, Sharath (Sharath)]

Hello,
We are using the westhawk stack version 5.0 in one of our management
applications, which connect to SNMPv3 based network elements (NEs).

We create the NE on the manager application and use the stack to
heartbeat (GET a couple of SNMP scalar attributes) the NE every 1
minute.
Once the NE is created on the manager, a new SnmpContext is also created
and cached till the NE is deleted from the application. Upon deleting
the NE, the context is also destroyed.
We are facing a situation where-in the engineId, engineBoots and
engineTime are in synch between the manager and the NE (authoritative
engine), up until some commands are executed on the NE which update the
snmp configuration. When these commands are executed on the NE, the
engineTime is being reset to 0 on the NE, but the engineBoots remains
the same.
When the manager now sends out the next heartbeat SNMP GET request, we
get a usmStatsNotInTimeWindows error since the local engineTime is
greater than the NE's engineTime.
The only way to recover from this situation is to restart the manager
application (and hence the stack), which we cannot afford to do. I
initially thought that once the context corresponding to the NE was
destroyed and re-created, it would re-discover by sending engineBoots=0
and engineTime=0, but the stack still retains the old values of
engineBoots and engineTime even if there is no corresponding context.

I tried to do a forced discovery whenever usmStatsNotInTimeWindows
exception was detected, but this does not update the timeline info.
I see from TimeWindow.updateTimeWindow(), that timeline is updated only
	if (bootsA > bootsL ||
               (bootsA == bootsL && timeA > latestL))

But in our case, bootsA == bootsL, but timeA < latestL.

Is there a way to recover from this situation?

Can you provide some public methods in TimeWindow.java to clear the
engineId and/or engineBoots and engineTime entries from the "hostLookup"
and "engineLookup" Hashtables?
This will enable us to re-initate a discovery and recover from this
situation.

Or

How about removing the corresponding entries in the hostLookup and
engineLookup Hashtables upon a context getting destroyed?
Because once the entries are stored for a given ip:port combination,
they remain for the lifetime of the stack, even if there is no context
associated with the given ip and port. Doesn't this seem wasteful?

Any other suggestions to overcome this situation will be helpful.

Thanks,
Sharath