April 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-212) Support property expansion in CLI command files

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/SRAMP-212?page=com.atlassian.jira.plugin.... ] David virgil naranjo updated SRAMP-212: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/395 > Support property expansion in CLI command files > ----------------------------------------------- > > Key: SRAMP-212 > URL: https://issues.jboss.org/browse/SRAMP-212 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 - API Management > > > Currently the CLI (sramp shell) supports the ability to pass it a file containing a list of commands to execute. This should be enhanced to support property expansion (standard Ant format), which would allow for more powerful/useful operation when integrating with e.g. Ant. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-425) Persistent retry capability

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-425?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-425: ---------------------------------- Further requirements: We need to make sure that local resources (i.e. disk space) are not consumed by the remote server being down for a long period of time, and the information just accumulating locally. So some thresholds need to be defined, with suitable notification mechanism, to ensure administrators are kept informed of the issue. Suitable thresholds may be related to the size of the information that has been reported, size of remaining space (e.g. filesystem) getting below a certain level, length of time oldest information has been stored without successful retry, etc. We need to make sure, once past a threshold, that the notifications are not continuously sent - only at the point where the threshold is breached. > Persistent retry capability > --------------------------- > > Key: RTGOV-425 > URL: https://issues.jboss.org/browse/RTGOV-425 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > In various parts of the rtgov architecture, information is reported to a remote service, and if that service is not available, the information is currently discarded. > This task is to provide an infrastructure capability (as part of overlord-commons) that can store information that cannot currently be reported to the remote service, and have it replayed once the remote service becomes available. > Some of the characteristics required are: > * When the primary component (reporting the information to the remote sevice) first starts up, it should register itself with the "persistent retry" capability, providing a handler that can be used to retry sending information to the remote service. > * When a failure occurs, attempting to send information to the remote service, the primary component will invoke the "persistent retry" capability to handle the information. > * The persistent retry capability will store information in a persistent form (initially file system, but other dbs etc should be supported in the future). > * When registering with the persistent retry capability, the primary component should be able to register a retry strategy. One implementation of such a strategy could be: > ** Periodically attempt to send retry information to its remote service via the registered handler. > ** If unsuccessful, then back off and wait for the next cycle. > ** If successful, then schedule another task to send the next information for that service until either a failure occurs, in which case wait for the next retry cycle, or no further information exists. A thread pool should be used across all retry handlers. > Investigate whether there are existing open source solutions for this problem. If not, then as part of building the solution, need to ensure that it is as efficient as possible in a multi-thread situation - so (for example) when looking at a persistent file system store, need to ensure that a suitable mechanism is used that caters for the multi-threaded updates (i.e. writing new records and clearing successfully retried records). Possibly a file based db may be one option to investigate. > JUnit tests need to be written that test the solution in a multi-threaded scenario. Profiling should be performed to understand the impact of this component on normal operations, and also when retries are being performed concurrently with new information being reported. > Places where this mechanism may be used: > 1) Activity collector > 2) ElasticSearch KeyValueStore -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-425) Persistent retry capability

by Gary Brown (JIRA)

Gary Brown created RTGOV-425: -------------------------------- Summary: Persistent retry capability Key: RTGOV-425 URL: https://issues.jboss.org/browse/RTGOV-425 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final In various parts of the rtgov architecture, information is reported to a remote service, and if that service is not available, the information is currently discarded. This task is to provide an infrastructure capability (as part of overlord-commons) that can store information that cannot currently be reported to the remote service, and have it replayed once the remote service becomes available. Some of the characteristics required are: * When the primary component (reporting the information to the remote sevice) first starts up, it should register itself with the "persistent retry" capability, providing a handler that can be used to retry sending information to the remote service. * When a failure occurs, attempting to send information to the remote service, the primary component will invoke the "persistent retry" capability to handle the information. * The persistent retry capability will store information in a persistent form (initially file system, but other dbs etc should be supported in the future). * When registering with the persistent retry capability, the primary component should be able to register a retry strategy. One implementation of such a strategy could be: ** Periodically attempt to send retry information to its remote service via the registered handler. ** If unsuccessful, then back off and wait for the next cycle. ** If successful, then schedule another task to send the next information for that service until either a failure occurs, in which case wait for the next retry cycle, or no further information exists. A thread pool should be used across all retry handlers. Investigate whether there are existing open source solutions for this problem. If not, then as part of building the solution, need to ensure that it is as efficient as possible in a multi-thread situation - so (for example) when looking at a persistent file system store, need to ensure that a suitable mechanism is used that caters for the multi-threaded updates (i.e. writing new records and clearing successfully retried records). Possibly a file based db may be one option to investigate. JUnit tests need to be written that test the solution in a multi-threaded scenario. Profiling should be performed to understand the impact of this component on normal operations, and also when retries are being performed concurrently with new information being reported. Places where this mechanism may be used: 1) Activity collector 2) ElasticSearch KeyValueStore -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-417) Add Bulk API support to ElasticSearchKeyValueStore

by ivan mckinley (JIRA)

[ https://issues.jboss.org/browse/RTGOV-417?page=com.atlassian.jira.plugin.... ] ivan mckinley reassigned RTGOV-417: ----------------------------------- Assignee: ivan mckinley (was: Gary Brown) > Add Bulk API support to ElasticSearchKeyValueStore > -------------------------------------------------- > > Key: RTGOV-417 > URL: https://issues.jboss.org/browse/RTGOV-417 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Reporter: ivan mckinley > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > > Currently the ElasticSearchKeyValueStore stores events in elastic search as it receives them. So 500 ActivityUnits will result in 500 communications with Elasticsearch. This is suboptimal for heavy load situations and could potentially result in unnecessary overhead for RTGov. > Recommendation is to add functionality to utilize RTGov bulk API in ElasticSearchKeyValueStore, http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/doc... > This will be enabled by a flag on the configuration of ElasticSearchKeyValueStore. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-239) Documentation insufficient

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-239?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-239: ----------------------------- Fix Version/s: 2.0.0.Final > Documentation insufficient > -------------------------- > > Key: RTGOV-239 > URL: https://issues.jboss.org/browse/RTGOV-239 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Environment: N/A > Reporter: Cojan van Ballegooijen > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > > Documentation insufficient: for example the REST interface > documentation is incomplete; for example paragraph 3.2.2 in the user > guide; which formats are supported, which expressions are supported, > what is the expression format, which objects can be used and how, etc? -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-284) Change JPA column name for timestamp as keyword in ORACLE

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-284?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-284: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/49 > Change JPA column name for timestamp as keyword in ORACLE > --------------------------------------------------------- > > Key: RTGOV-284 > URL: https://issues.jboss.org/browse/RTGOV-284 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-284) Change JPA column name for timestamp as keyword in ORACLE

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-284?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-284. ------------------------------ Fix Version/s: 2.0.0.Final Resolution: Done > Change JPA column name for timestamp as keyword in ORACLE > --------------------------------------------------------- > > Key: RTGOV-284 > URL: https://issues.jboss.org/browse/RTGOV-284 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-291) RTGov client install fails to accept password

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-291?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-291. ------------------------------ Fix Version/s: 2.0.0.Final Resolution: Done > RTGov client install fails to accept password > --------------------------------------------- > > Key: RTGOV-291 > URL: https://issues.jboss.org/browse/RTGOV-291 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When running "mvn install -Dtype=client", the script now requests the RTGov server's username and password. > When the username is entered, the script aborts with the following error: > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8-SNAPSHOT:run (install) on project install: An Ant BuildException has occured: The following error occurred while executing this line: > [ERROR] /home/gbrown/repositories/overlord/objectiser/rtgov/release/jbossas/distribution/target/overlord-rtgov-jbossas-2.0.0-SNAPSHOT/profiles/client/build.xml:49: Failed to read input from Console. > [ERROR] around Ant part ...<ant antfile="profiles/client/build.xml" target="deploy">... @ 6:60 in /home/gbrown/repositories/overlord/objectiser/rtgov/release/jbossas/distribution/target/overlord-rtgov-jbossas-2.0.0-SNAPSHOT/target/antrun/build-main.xml: Stream closed > {noformat} > It appears that this is a fixed issue in ant version 1.8.3: https://issues.apache.org/bugzilla/show_bug.cgi?id=51161 > However the maven-ant-plugin 1.7 and 1.8-SNAPSHOT both use version 1.8.2 currently. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-372) ActivityStore implementation of the Metrics Provider API

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-372?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-372: ----------------------------- Fix Version/s: 2.0.0.Final > ActivityStore implementation of the Metrics Provider API > -------------------------------------------------------- > > Key: RTGOV-372 > URL: https://issues.jboss.org/browse/RTGOV-372 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Obtain service metrics from the ActivityStore. > Additional (optional) config information should be used to narrow down the timeframe used to derive the metric information. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-295) Support deployment in EAP without switchyard

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-295?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-295: ---------------------------------- This could be resolved as part of supporting domain mode. > Support deployment in EAP without switchyard > -------------------------------------------- > > Key: RTGOV-295 > URL: https://issues.jboss.org/browse/RTGOV-295 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- 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, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues April 2014