Storing duplicated parameter events when reconnecting
When an attribute that requires polling is configured for archiving, and then later someone turns off polling for whatever reason, the archiver appears to have some inner loop that checks again roughly every minute. In the stdout I periodically see messages like
Tango exception
Severity = ERROR
Error reason = API_AttributePollingNotStarted
Desc : The polling (necessary to send events) for the attribute long_scalar is not started
Origin : DServer::event_subscription
(This is another thing, I would expect this to go to the logfile instead, but I think we have another issue about this)
Anyway what I can also see is that each time this happens, we also store a row in the att_parameter table for the attribute. This means that there is a constant buildup of "false" parameter changes, one per minute. While not exactly wrong, this means the parameter table can start growing for no particular reason.
My guess is that this happens because the archiver is trying to resubscribe to the attribute, and even if lack of polling prevents the archive events subscription, the subscription to config events works. But it's not very useful here. Perhaps the config subscription could be conditioned, so that it's only done if the other subscription also works? Is it ever useful to store these parameter events for an otherwise broken attribute?