[JBoss JIRA] (RTGOV-415) ElasticSearch Activity Store implementation
by ivan mckinley (JIRA)
[ https://issues.jboss.org/browse/RTGOV-415?page=com.atlassian.jira.plugin.... ]
ivan mckinley reassigned RTGOV-415:
-----------------------------------
Assignee: ivan mckinley (was: Gary Brown)
> 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-421) Make ElasticSearch EventProcessor more generic
by ivan mckinley (JIRA)
[ https://issues.jboss.org/browse/RTGOV-421?page=com.atlassian.jira.plugin.... ]
Work on RTGOV-421 started by ivan mckinley.
> Make ElasticSearch EventProcessor more generic
> ----------------------------------------------
>
> Key: RTGOV-421
> URL: https://issues.jboss.org/browse/RTGOV-421
> Project: RTGov (Run Time Governance)
> Issue Type: Sub-task
> Reporter: Gary Brown
> Assignee: ivan mckinley
> Fix For: 2.0.0.Final
>
>
> As discussed in forum post (point 3), as the ElasticSearch capabilities are now encapsulated in the KeyValueStore implementation, it makes sense to make the EventProcessor more generic to cater for any key/store implementation.
> As pointed out by Ivan, some custom capabilities may be required by particular KeyValueStore implementations (e.g. MongoDB, Cassandra), but these can be added later as extensions to the generic event processor.
--
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-337) Batch retry of messages
by Michael Clay (JIRA)
[ https://issues.jboss.org/browse/RTGOV-337?page=com.atlassian.jira.plugin.... ]
Michael Clay resolved RTGOV-337.
--------------------------------
Resolution: Done
> Batch retry of messages
> -----------------------
>
> Key: RTGOV-337
> URL: https://issues.jboss.org/browse/RTGOV-337
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Components: User Interface
> Reporter: Gary Brown
> Assignee: Michael Clay
> Fix For: 2.1.0.Final
>
>
> Add a new region below the filter related to batch retries.
> Options:
> Provide a checkbox to ask whether previously submitted messages should be submitted again. Default should be false.
> Only resubmit message if a 'resubmit' property is associated with the situation, identifying the provider to handle the resubmission (currently only 'switchyard' supported).
> Result of the resubmission should be a status popup (similar to the one displayed after a single message submission), showing the number of messages successfully resubmitted, failed and ignored (i.e. situations that either did not have a message or 'resubmit' property).
--
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