ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (ACE-230) Avoid removed targets to be resurrected by their audit log.
Date Mon, 14 Oct 2013 06:32:46 GMT

     [ https://issues.apache.org/jira/browse/ACE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marcel Offermans resolved ACE-230.
----------------------------------

    Resolution: Fixed

Wrapped up the analysis in the wiki. We now make the discovery of unregistered targets optional,
but do not implement a "deleted" flag because we feel it's not the right thing to do in the
generic case. However, the mechanism that was described in the analysis can easily be implemented
on top of ACE, by adding a property and a filter condition, if desired.

> 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
>          Components: Architecture
>            Reporter: J.W. Janssen
>            Assignee: Marcel Offermans
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message