June 2014 - overlord-issues - Jboss List Archives

[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 updated RTGOV-329: ----------------------------- Attachment: Performance.java (1) Clear vs allocation Results: {noformat} TIME TAKEN (clear) arraysize=10 iterations=1000: 31 TIME TAKEN (alloc) arraysize=10 iterations=1000: 4 ----- TIME TAKEN (clear) arraysize=10 iterations=1000: 0 TIME TAKEN (alloc) arraysize=10 iterations=1000: 1 ----- TIME TAKEN (clear) arraysize=100 iterations=1000: 7 TIME TAKEN (alloc) arraysize=100 iterations=1000: 15 ----- TIME TAKEN (clear) arraysize=1000 iterations=1000: 36 TIME TAKEN (alloc) arraysize=1000 iterations=1000: 40 ----- TIME TAKEN (clear) arraysize=10000 iterations=1000: 448 TIME TAKEN (alloc) arraysize=10000 iterations=1000: 699 ----- TIME TAKEN (clear) arraysize=100000 iterations=1000: 3518 TIME TAKEN (alloc) arraysize=100000 iterations=1000: 3649 ----- {noformat} The first pair of results are just startup costs - so this test is repeated and the second run shows the more realistic results. So it shows with array sizes up to 100000, using clear performs better than reallocating each time. > 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, 6 months

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 closed RTGOV-328. ---------------------------- Resolution: Done Closing the issue - please reopen if you think there are valid reasons for implementing this. > 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, 6 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on RTGOV-328: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1056447|https://bugzilla.redhat.com/show_bug.cgi?id=1056447] from NEW to CLOSED > 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, 6 months

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 edited comment on RTGOV-328 at 6/18/14 12:00 PM: ------------------------------------------------------------ Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better that concurrency and asynchrony should possibly just be handled on the client side? was (Author: objectiser): Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better to concurrency and asynchrony should possible just be handled on the client side? > 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, 6 months

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: ---------------------------------- Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better to concurrency and asynchrony should possible just be handled on the client side? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-257) Allow parametrization of (not only) MVEL scripts in EPN

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-257?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-257: ----------------------------- Fix Version/s: 2.0.0.Final (was: 2.1.0.Final) > Allow parametrization of (not only) MVEL scripts in EPN > ------------------------------------------------------- > > Key: RTGOV-257 > URL: https://issues.jboss.org/browse/RTGOV-257 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > EPN allows to use MVEL or Java class as processor or predicate. > It would be great addition to re-usability of the scripts and classe if it > would be possible to pass a set of parameters from epn.json to the > processor/evaluator for the instance. > It could work in a similar way as injection of services - via EPNContext. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-393) S-RAMP Archive Util fails for out-of-order zip files

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-393?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-393: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1094181|https://bugzilla.redhat.com/show_bug.cgi?id=1094181] from NEW to MODIFIED > S-RAMP Archive Util fails for out-of-order zip files > ---------------------------------------------------- > > Key: SRAMP-393 > URL: https://issues.jboss.org/browse/SRAMP-393 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Bug in this line of code: > https://github.com/Governance/s-ramp/blob/master/s-ramp-atom/src/main/jav... > If the zip file entries are out of order, that line could fail because the folder was already created. Simple fix is to check for the existence of that folder first before trying to create it. > Also, we probably need to do a mkdirs() on it, since it might occur before its parent directory entry. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-395) S-RAMP allows artifacts to be created with invalid characters in the Artifact Type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-395?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1085429|https://bugzilla.redhat.com/show_bug.cgi?id=1085429] from NEW to MODIFIED > S-RAMP allows artifacts to be created with invalid characters in the Artifact Type > ---------------------------------------------------------------------------------- > > Key: SRAMP-395 > URL: https://issues.jboss.org/browse/SRAMP-395 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0.Final > > > There are two ways (I believe) that users can mistakenly create artifacts with an invalid artifact type. The first is via the CLI: > {code} > s-ramp:upload /path/to/file.ext "Invalid Type" > s-ramp:create "Invalid Type" "Valid Artifact Name" "Description goes here." > {code} > The other is via the s-ramp UI's Import Artifact dialog. This dialog allows the user to type in any Artifact Type they want, which is an opportunity to mess it up. > We need to make sure we have appropriate validation of any custom Artifact Type provided by the user on the server (probably in the REST layer). > For bonus points we can add validation to the UI and CLI to prevent the request from even being made to the server unless it's valid. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-388) Use jboss version of javax.servlet GAV consistently

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-388?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-388: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1081519|https://bugzilla.redhat.com/show_bug.cgi?id=1081519] from NEW to MODIFIED > Use jboss version of javax.servlet GAV consistently > --------------------------------------------------- > > Key: SRAMP-388 > URL: https://issues.jboss.org/browse/SRAMP-388 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Alpha1, 0.5.0.Final > > > EAP uses the GAV > {code} > <dependency> > <groupId>org.jboss.spec.javax.servlet</groupId> > <artifactId>jboss-servlet-api_3.0_spec</artifactId> > </dependency> > {code} > rather than > {code} > <dependency> > <groupId>javax.servlet</groupId> > <artifactId>servlet-api</artifactId> > </dependency> > {code} > This GAV is also available in the community BOM. > We need to remove all references to the javax.servlet:servlet-api dependency in all Overlord projects (s-ramp, dtgov, overlord-commons, etc). Anywhere we reference that GAV please change it to org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-433) Create a proper Event producer for s-ramp

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/SRAMP-433?page=com.atlassian.jira.plugin.... ] Gary Brown commented on SRAMP-433: ---------------------------------- Might be useful for DTGOV-123 to use notifications from SRAMP that are distributed via a JMS queue, to enable it to load balance its handling of the artifact events. This would mean that the SRAMP notifier (JMS impl) would need to be configurable to allow topics or queues to be used. Multiple notifiers may also be required with different impls and configurations - e.g. might have two JMS notifiers configured, one with a queue and one with topic. > Create a proper Event producer for s-ramp > ----------------------------------------- > > Key: SRAMP-433 > URL: https://issues.jboss.org/browse/SRAMP-433 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently dtgov monitors s-ramp for changes by polling. It would be more efficient if dtgov could listen for events it cared about. > Ideally we could add a listener to the s-ramp repository either at the global level or by including a filter of some kind, so we can make sure to get only a subset of the total events coming from the server. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

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