[overlord-issues] [JBoss JIRA] (RTGOV-154) Situation list filter

[Gary Brown (JIRA)]

    [ https://issues.jboss.org/browse/RTGOV-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781201#comment-12781201 ] 

Gary Brown commented on RTGOV-154:
----------------------------------

Refactored services (e.g. CacheManager) used by event processor to be available as a common component (RTGOV-214), to enable the active collection predicate to also be able to use it.

Add a context parameter supplied to the predicates (used to filter derived active collections) to enable additional active collections and services to be used by the predicate.

Current thoughts on solution are:

a) have a second active collection (backed by an infinispan cache) to represent the list of components with known issues (i.e. not to be displayed)

b) have a derived collection from the current Situations active collection, that will use the new active collection from (a) to filter out the situations that are related to known issues
- as the result of the derived collection may change, based on the (a) active collection, we need a way to refresh the derived collection list. This could be achieved a couple of ways:
(i) use active notifications from the (a) collection to update the list, but this would require some additional logic to be provided to understand the active notifications and apply the changes
(ii) use active notifications to prompt a re-evaluation of the complete derived collection - may be ok in this case, although could generate alot of work if there any many changes to collection (a)
(iii) enable the derived collection to be configured as not storing actual results (i.e. just use it as a proxy to generate notifications), and when the list is requested the parent collection is fully evaluated against the predicate - this should be ok if the complete list is only requested periodically.

c) update gadget to use the derived Situations collection rather than the full list

d) provide a REST service to enable components to be added and removed from the known issues list - possibly also a JMX action


To support (b), we also need to pre-configure the derived collection as part of the top level collection's ActiveCollectionSource, and also mark the derived collection as permanent (i.e. it shouldn't be removed when no clients).

Currently option (b) (iii) is most likely to be implemented.
                
> Situation list filter
> ---------------------
>
>                 Key: RTGOV-154
>                 URL: https://issues.jboss.org/browse/RTGOV-154
>             Project: RTGov (Run Time Governance)
>          Issue Type: Feature Request
>            Reporter: Gary Brown
>            Assignee: Gary Brown
>            Priority: Critical
>             Fix For: 1.0.0.Final
>
>
> Situation events are created when an event processor detects a problem based on activity information generated by executing business transactions.
> The situations are associated with a target component that indicates where the problem has arisen. In some situations, a particular component may be known to an administrator, and therefore they wish to temporarily ignore any problems being reported about it.
> Although this filtering could be provided in the presentation layer, it may be better that it is centrally managed, to enable other applications that access the Situations list through the REST API to also be subject to the same filtering.
> The issue is where to apply this filter, and where will it get the list of blacklisted entries from. In terms of the filter, should the overall list remain unchanged, and just have a derived list that applies the filter?
> If the complete list is maintained, then the benefit is that when the component is removed from the blacklist, its associated Situations would then immediately re-appear within the displayed list.
> The other point to consider is whether Situations associated blacklisted components should be persisted, or atleast marked to indicate that they were flagged as a known problem?
> As this mechanism is primarily intended to de-clutter the UI, to avoid known problems overshadowing other Situations that may occur, it is likely that persisting Situation events would be unaffected by this mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira