[JBoss JIRA] (RTGOV-416) Investigate solution for deploying ElasticSearch EPN on FSW 6.0
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-416?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-416:
-----------------------------
Parent: RTGOV-419
Issue Type: Sub-task (was: Task)
> Investigate solution for deploying ElasticSearch EPN on FSW 6.0
> ---------------------------------------------------------------
>
> Key: RTGOV-416
> URL: https://issues.jboss.org/browse/RTGOV-416
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> This task is to investigate options for supporting ElasticSearch capabilities in FSW 6.0.
> RTGOV-342 has provided an event processor for ElasticSearch. However this introduces a new 'service' to represent a KeyValueStore, which ElasticSearch is the first implementation.
> If we want to deploy an ElasticSearch based EPN, this new abstract class (currently located in rtgov-commons) is the only issue.
> There are two current proposed solutions:
> 1) Move the abstract class (within the same package) into the rtgov-elasticsearch package as a temporary measure for the next release.
> The issue with this potential solution is if the jars in FSW6.0 are signed - then it won't be possible to have two jars containing classes in the same package.
> 2) Another temporary solution for the next community release would be to inherit the ElasticSearchKeyValueStore directly from the Service abstract class.
> The implication of this would be the EPN's would need to directly use the ElasticSearchKeyValueStore class, rather than the more generic KeyValueStore class - which means that it won't simply be a configuration change to be able to use an alternative KeyValueStore implementation.
> However, as the ElasticSearchKeyValueStore will be the only implementation at that point, then this would work - we would just need to remember to change the EPN's java code after the release, to again use the generic KeyValueStore abstract class.
> At this point, the second option appears to be best, as it localises the changes to the rtgov-elasticsearch module. The rtgov-commons module can remain untouched.
--
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
10 years, 8 months
[JBoss JIRA] (RTGOV-342) ElasticSearch Event Processor implementation
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-342?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-342:
-----------------------------
Parent: RTGOV-419
Issue Type: Sub-task (was: Feature Request)
> ElasticSearch Event Processor implementation
> --------------------------------------------
>
> Key: RTGOV-342
> URL: https://issues.jboss.org/browse/RTGOV-342
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: ivan mckinley
> Fix For: 2.0.0.Final
>
>
> The EventProcessor configuration should be provided with:
> a) Index name
> b) Type name
> c) MVEL expression for obtaining id from the event
> NOTE: Also need to be able to indicate that a random id should be used - possibly if mvel expression is not defined?
> If REST call does not succeed, then throw exception to prompt a retry of the event.
--
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
10 years, 8 months
[JBoss JIRA] (RTGOV-415) ElasticSearch Activity Store implementation
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-415?page=com.atlassian.jira.plugin.... ]
Gary Brown updated RTGOV-415:
-----------------------------
Parent: RTGOV-419
Issue Type: Sub-task (was: Feature Request)
> ElasticSearch Activity Store implementation
> -------------------------------------------
>
> Key: RTGOV-415
> URL: https://issues.jboss.org/browse/RTGOV-415
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: ivan mckinley
> Fix For: 2.0.0.Final
>
>
> Although it is not currently clear whether organisations would rely on ElasticSearch as a database for their activity information, it will be good to be able to offer it as an alternative.
> If configured, then it will store the ActivityUnit, and any subsequent EPN can be used to store the derived information (e.g. situations and response times).
> ElasticSearch has improved its support for backup/restore, so could potentially be used as a primary db for this type of information - although it is not transactional.
> The module should be defined in modules/activity-management/activity-store-es (or elasticsearch - whatever is consistent with RTGOV-342).
--
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
10 years, 8 months
[JBoss JIRA] (RTGOV-418) Bulk event processor capability
by Gary Brown (JIRA)
Gary Brown created RTGOV-418:
--------------------------------
Summary: Bulk event processor capability
Key: RTGOV-418
URL: https://issues.jboss.org/browse/RTGOV-418
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Components: Event Processor
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.0.0.Final
Currently the EventProcessor implementations are invoked to process individual events that pass an optional predicate.
For some EventProcessor implementations, it may be more efficient to deal with a group of events at the same time.
There are two ways that this could be dealt with:
(a) maintain the single processing approach, and the implementation builds up the state locally - and potentially uses the txn commit as an indication to record the events - although means maintaining state against the txn/thread.
(b) extend the event processor API to enable a collection of events (that have passed the predicate) to be provided in one go - it would then return a set of those events that need to be retried.
Current preference is for (b), as it does not require any reliance on txn or maintaining state.
--
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
10 years, 8 months