Avoid removed targets to be resurrected by their audit log.
-----------------------------------------------------------
Key: ACE-230
URL: https://issues.apache.org/jira/browse/ACE-230
Project: ACE
Issue Type: New Feature
Reporter: J.W. Janssen
The basic fix for ACE-167 allows targets to be removed. However, when there's
an audit log present for a target, it will cause the target to be resurrected
upon synchronization of the logs. This is not desired. Either the audit log for
a target should be purged, or during the audit log synchronization it should
detect somehow that a target is removed, thereby avoiding it to be resurrected.
There are several possibilities for fixing this:
* purge the entire audit log at the server; when the target is no longer
running, the audit log will be recreated for the remaining targets. This won't
work if the target is still running (which is rather exotic in this situation),
or if there are relay server(s) present to which the removed target once
talked. These relay(s) do not have a notion that the target is removed, thus
will happily sent their audit logs to the main server, including the one for
the removed target. For development situations, this might not be an issue as
there are probably no relays involved;
* add a deleted timestamp attribute to the target object, and not really remove
it from the repository. This timestamp will be used during the synchronization
process to determine whether there are *new* events that should cause the
target to be resurrected. If there are no newer events (i.e., the event
timestamp > deleted timestamp), the target will not be recreated. The only
thing is that removed targets still remain in the repository, thus need to be
hidden in the UI;
* make the audit log merge process smarted, for example, by only merging audit
logs for targets seen in the last N seconds. In combination with a purge of the
entire audit log at the server and some patience, it would prevent a removed
target to be resurrected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
