June 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Jiri Pechanec (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- The @Singleton bean in question uses container managed concurrency >From the EJB spec - By default, the value of the lock associated with a method of a bean with container managed concurrency is a write lock (exclusive lock). When synchronization primitives are used the @Singleton bean should use bean managed concurrency using @ConcurrencyManagement(ConcurrencyManagementType.BEAN) See 4.8.5.2 and 4.8.5.4 in EJB spec > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-329: ---------------------------------- Not sure what JEE synchronization is in play here? > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-328: ---------------------------------- Currently the invocation on the server is performed within a txn, if there is a failure there is the potential to fail over and handle the activities on a different server. Using the approach you suggest, it would cause any queued activities awaiting processing to be lost, and no way to know what has been lost. In environments that don't care about lost activities, then possibly an option could be provided. > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events

by Jiri Pechanec (JIRA)

[ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.... ] Jiri Pechanec reopened RTGOV-328: --------------------------------- The reason is pretty simple - I believe that activity collection should have as least impact as possible on the client system. If we delegate the async processing on the server then it is fire-and-forget on the side on client with a minimum performance impact. If we keep it on client then some of the CPU cycles of the monitored system will be spent on activity processing. > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Jiri Pechanec (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- In case of 3) - I am not sure it is wise to mix two completely independent ways of synchronization - one handled by Java EE server and the second manual just via synchronized keyword. I would not be surprised if such a situation would lead to a rare but still possible deadlock hidden inside. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-462) Explore whether ElasticSearch server can be embedded into container (EAP)

by ivan mckinley (JIRA)

[ https://issues.jboss.org/browse/RTGOV-462?page=com.atlassian.jira.plugin.... ] Work on RTGOV-462 started by ivan mckinley. > Explore whether ElasticSearch server can be embedded into container (EAP) > ------------------------------------------------------------------------- > > Key: RTGOV-462 > URL: https://issues.jboss.org/browse/RTGOV-462 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-503) Filtered situation list caused all situations to be removed when doing bulk delete

by Gary Brown (JIRA)

Gary Brown created RTGOV-503: -------------------------------- Summary: Filtered situation list caused all situations to be removed when doing bulk delete Key: RTGOV-503 URL: https://issues.jboss.org/browse/RTGOV-503 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Need to reproduce, but when using the situation list with multiple SLA violations and single Exception, filtered based on the Exception type and then tried doing a bulk delete - it should have just deleted the single situation, but deleted 5. The confirmation message should show the number of situations that will be deleted. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-502?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-502. ------------------------------ Resolution: Done > ElasticsearchSituationStore query on properties not working > ----------------------------------------------------------- > > Key: RTGOV-502 > URL: https://issues.jboss.org/browse/RTGOV-502 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-502?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-502: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/127 > ElasticsearchSituationStore query on properties not working > ----------------------------------------------------------- > > Key: RTGOV-502 > URL: https://issues.jboss.org/browse/RTGOV-502 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working

by Gary Brown (JIRA)

Gary Brown created RTGOV-502: -------------------------------- Summary: ElasticsearchSituationStore query on properties not working Key: RTGOV-502 URL: https://issues.jboss.org/browse/RTGOV-502 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2014