ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-230) Avoid removed targets to be resurrected by their audit log.
Date Mon, 19 Mar 2012 09:31:37 GMT

    [ 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

        

Mime
View raw message