[JBoss JIRA] (RTGOV-337) Batch retry of messages
by Gary Brown (JIRA)
Gary Brown created RTGOV-337:
--------------------------------
Summary: 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: Gary Brown
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
[JBoss JIRA] (RTGOV-336) Combine activities recorded across multiple threads
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-336?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-336:
----------------------------------
Actually the case in question was caused by a delay in the InventoryServiceBean (wait 500 ms) when item was JAM.
> Combine activities recorded across multiple threads
> ---------------------------------------------------
>
> Key: RTGOV-336
> URL: https://issues.jboss.org/browse/RTGOV-336
> Project: RTGov (Run Time Governance)
> Issue Type: Enhancement
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.M1
>
>
> When capturing activity events via proxies in JBoss Fuse, found that when a service returned an exception, it was handled in a separate thread.
> This resulted in two separate activity units, one for the activities up until the exception, and the other for the activities following the exception.
> This will cause issues with correlation currently, where request/response pairs are expected to be in the same activity unit.
> Two possible solutions:
> (1) work on the correlation of requests/responses across activity units - which will be useful in a wider range of cases.
> (2) enable activities across multiple threads to be combined - i.e. if a subsequent thread is new, allow its relationship with a previous activity event (e.g. the request) to link it to the same activity unit. Not sure of the implications on the API for this.
> This work is related to RTGOV-325.
--
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-336) Combine activities recorded across multiple threads
by Gary Brown (JIRA)
Gary Brown created RTGOV-336:
--------------------------------
Summary: Combine activities recorded across multiple threads
Key: RTGOV-336
URL: https://issues.jboss.org/browse/RTGOV-336
Project: RTGov (Run Time Governance)
Issue Type: Enhancement
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.0.0.M1
When capturing activity events via proxies in JBoss Fuse, found that when a service returned an exception, it was handled in a separate thread.
This resulted in two separate activity units, one for the activities up until the exception, and the other for the activities following the exception.
This will cause issues with correlation currently, where request/response pairs are expected to be in the same activity unit.
Two possible solutions:
(1) work on the correlation of requests/responses across activity units - which will be useful in a wider range of cases.
(2) enable activities across multiple threads to be combined - i.e. if a subsequent thread is new, allow its relationship with a previous activity event (e.g. the request) to link it to the same activity unit. Not sure of the implications on the API for this.
This work is related to RTGOV-325.
--
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-274) Karaf support
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-274?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-274:
----------------------------------
Remaining work:
IP, AV, JPA Activity Store, JPA EP
Example using ActivityReporter, CollectionManager and Validator.
Switch REST services to use RESTEasy.
> Karaf support
> -------------
>
> Key: RTGOV-274
> URL: https://issues.jboss.org/browse/RTGOV-274
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.M1
>
>
> Enable rtgov to be installed in Karaf.
> Initial priority should be for a client based installation, but eventually enable 'all' profile to be supported as well.
--
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