[
https://issues.apache.org/jira/browse/ACE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232526#comment-13232526
]
Marcel Offermans commented on ACE-230:
--------------------------------------
Thanks for sharing these thoughts. Logs, more specifically audit logs, are
indeed first class citizens. They are created on the target, and replicated
throughout the system (which can consist of a single server, but also more
complex topologies with multiple relay servers). This makes deleting all
"evidence" of a target more complex, as all of these systems are designed to
replicate the data if it somehow goes missing (so if you delete it in one
place, and this node starts replicating again, it will fetch the missing data
again).
Specifically for a development scenario, we can overcome this problem, because
a) it only involves a single, locally running server and b) it only involves
one (or a few) targets which will be deleted quite often. In such scenarios, if
we have CRUD for the logs on the server, we can simply erase them there and
there will be no place that still holds a copy.
For the section scenario, we should indeed go for some kind of flag. Just to
make things 100% clear. ACE does not ever "register" a target automatically
(unless you write custom code to do so). The only thing it does is show targets
that have tried to poll the server, which is a convenience feature for people
using the UI (so they can quickly "register" the target without having to
manually type its identification). Having more options to filter the
information that is shown in the target column (for example, only show
*registered* targets, or only show targets that we've heard from in the last 5
minutes) would also help.
The identification of a target is unique, so whoever connects with that same
identity is assumed to be the same target. If you don't want that, use a
different identity each time. We can indeed, for the UI, add a "display name"
to the target that can be shown instead of (or next to) the identity. I think
something like that is a valid enhancement.
> 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
