Re: chart types discussion
by Charles Crouch
Thats an interesting idea Andreas. I had assumed that the "summary" and "detailed" charts being different was a bad thing, but maybe we could have the "summary" graphs be regular area charts, and the "detailed" chart view show the more precise floating column based chart. On the detailed chart page there should be more room for a textual description of what is going on too, which would help explain what the non-standard chart is trying to show.
Like I said before we need to have some of these different chart types rendered with real world data sets and pixel areas.
Cheers
Charles
----- "Andreas Dietrich" <adi(a)aspicon.de> wrote:
> Hi,
>
> sorry if I misundestood something ... I did not follow the whole
> discussion.
> If possible we should try to implement a solution supporting both
> graphical representations:
>
> 1. the standard "easy to understand, fancy looking, but maybe
> inaccurate" graphs and
> 2. the optional "unfamiliar, more complex, but (more) accurate" graphs
>
> Thanks
> Andreas :-)
>
>
> On 10/28/2010 11:10 AM, Joseph Marques wrote:
>
> On 10/28/2010 12:49 AM, Charles Crouch wrote:
>
> I * think * this was the point Greg was trying to make, the horizontal
> width of the bar implies to the user, since time is the y-axis, that
> there is a period of time related to the data collection which is
> important. When there really isn't, its just an artifact of how we are
> doing data bucketing. Actually, the horizontal width of the bar is
> important because provides boundaries for each timeslice, which have
> specific start/end times relative to the overall time range being
> viewed. This is a very accurate type of chart insofar as the
> mix/max/avg markers are calculated with respect to the timeslice
> boundaries.
>
> Contrast with that a line chart which turns those timeslices into
> single points (and then connects the dots between two points in
> temporal order). The algorithm for querying data uses buckets that
> have a non-zero width along the y-axis (time), but then the graph is
> displaying that bucket as a single point (no width) connected to the
> next single point (no width).
>
> All that said, I'm willing to concede that single points are probably
> more intuitive to a lay user than bars. I just wanted to be clear that
> intuitiveness was the driving factor here. I didn't and don't believe
> that candlestick is any worse at displaying point-in-time bucketed
> data than it is at displaying continuous bucketed data - the bucketing
> naturally normalizes the input from these sources. And it was agreed
> in #rhq that the jitter affect from bucketing would be present and
> need to be handled regardless of chart type. My primary concern was to
> thoroughly understand the ideas being presented, so that the wiki
> could be updated to better elaborate on the pain points of our current
> solution and accurately reflect how other solutions (such as line
> graphs) could mitigate those issues.
>
>
> If you use a point or line graph, then this initial confusion maybe
> mitigated. The actual datapoints don't change, so people could still
> ask over what period do we calculate the average, but its perhaps not
> the first thing they think of. Yes, this is what I thought the
> conclusion was in #rhq yesterday. It didn't seem like we were talking
> about getting rid of bucketing (and so any chart type would still need
> to deal with potential jitters, or somehow make the buckets
> consistent). I agree that a line chart is easier on the eyes, but
> don't believe that we are fundamentally changing what we are charting
> (bucketed data); we're just playing connect-the-dots (instead of
> bars/ticks) which, again, I'm willing to concede may be a more
> intuitive solution (even if it's not as accurate because it reduces
> data buckets [which have real width] to single points [which have no
> width]).
> _______________________________________________
> rhq-devel mailing list rhq-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
13 years, 6 months
coregui.war gwt-compiler build settings
by Ian Springer
By default, coregui will now be gwt-compiled for all browsers that GWT
supports, and compiler optimizations are enabled. These are the settings
we want for CI/QA builds and releases, but for everyday development,
developers will want to only compile for the browser they're using (e.g.
Firefox 3) and disable the compiler optimizations, in order to minimize
the time it takes to build the coregui war. The following comments from
coregui/pom.xml document the two Maven properties (gwt.userAgent and
gwt.draftCompile) that can be used to override these two settings:
<properties>
<!--
This property is substituted, by the resource plugin during
the resources phase, as the
value of the user.agent property in RHQDomain.gwt.xml and
CoreGUI.gwt.xml. The default
value results in these GWT modules being compiled into
JavaScript for all supported
browsers. To limit compilation to your preferred browser(s) to
speed up compile time,
specify the user.agent property on the mvn command line (e.g.
-Duser.agent=gecko1_8)
or in your ~/.m2/settings.xml
As of GWT 2.0.4, the recognized agents (defined in
gwt-user.jar:com/google/gwt/user/UserAgent.gwt.xml) are as
follows:
ie6: IE6/IE7
ie8: IE8
gecko: FF2
gecko1_8: FF3
safari: Safari/Chrome
opera: Opera
Multiple agents can be specified as a comma-delimited list, as
demonstrated by the
default value below.
-->
<gwt.userAgent>ie6,ie8,gecko,gecko1_8,safari,opera</gwt.userAgent>
<!-- Override this via mvn command line or your ~/.m2/settings.xml to
speed up
compilation. -->
<gwt.draftCompile>false</gwt.draftCompile>
</properties>
Here is what I have in my settings.xml:
<profile>
<id>dev</id>
<properties>
...
<!-- Only gwt-compile JavaScript for Firefox 3.x. -->
<gwt.userAgent>gecko1_8</gwt.userAgent>
<!-- Enable faster, but less-optimized, gwt compilations. -->
<gwt.draftCompile>true</gwt.draftCompile>
</properties>
</profile>
13 years, 6 months
Virtual platforms
by Heiko W.Rupp
Hi,
we currently have a fixed relations between servers and their platform. A server can basically only
exist when there is a platform resource in inventory which requires an agent on that box.
Of course it is possible to open remote connections to other machines, but those other
machines appear below the actual platform. This is most often no issue, but when you
e.g. want to include network elements like routers and switches, this does not work well.
Same issue arises when one goes through some "proxy" - e.g. a different management
server that manages some software and then provides that data to RHQ. Also in the
cloud case of e.g. Infinispan or Hadoop, there is often a cluster manager that provides
all the data and putting an agent on each box with an ISPN or Hadoop node is overkill.
So I propose that we introduce a concept of virtual platforms which also show up
in the tree as now, but which do not host agents (and are probably limited in the
data they can provide as without agent, there are not platform plugins and no platform metrics).
Software that is hosted on such a platform would show up as a normal platform child.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 6 months
Re: fix for MeasurementScheduleManagerBean.update
by Joseph Marques
Ian, interesting fix.
Looks like the enhancement for
'modifyDefaultCollectionIntervalForMeasurementDefinitions(4 args)' to
support the amended JDoc was relatively straightforward. However, I
think the logic:
- boolean enableDisable = (collectionInterval> 0);
+ boolean enable = (collectionInterval>= 0);
Should move into
'modifyDefaultCollectionIntervalForMeasurementDefinitions(5 args)' which
implements the actual update logic. This will allow existing and future
call paths to have the same post-condition.
Looking deeper into
'modifyDefaultCollectionIntervalForMeasurementDefinitions(5 args)', I
notice that we don't do any validation on the 'collectionInterval'
parameter. When updating measurement schedules we make sure to call the
'verifyMinimumCollectionInterval' method, but we don't seem to prevent
users from setting default collection intervals to invalid values.
Can you add that validation?
On 10/29/2010 07:44 PM, ips wrote:
...
> modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/measurement/MeasurementScheduleManagerBean.java | 15 +-
> 7 files changed, 143 insertions(+), 36 deletions(-)
>
> New commits:
> commit 0a0aa07d0e4cdf71b1dee4a7631bd70e50715072
> Author: Ian Springer<ian.springer(a)redhat.com>
> Date: Fri Oct 29 19:43:38 2010 -0400
>
> add support to metric template view for specifying whether existing schedules should be updated
...
> diff --git a/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/measurement/MeasurementScheduleManagerBean.java b/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/measurement/MeasurementScheduleManagerBean.java
> index ccd65bc..3dc8b05 100644
> --- a/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/measurement/MeasurementScheduleManagerBean.java
> +++ b/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/measurement/MeasurementScheduleManagerBean.java
> @@ -332,13 +332,16 @@ public class MeasurementScheduleManagerBean implements MeasurementScheduleManage
> }
...
> + * @param collectionInterval if> 0, enable the metric with this value as the the new collection
> + * interval, in milliseconds; if == 0, enable the metric with its current
> + * collection interval; if< 0, disable the metric
> * @param updateExistingSchedules If true, then existing schedules for this definition will also be updated.
> */
> @RequiredPermission(Permission.MANAGE_SETTINGS)
> @@ -358,13 +361,13 @@ public class MeasurementScheduleManagerBean implements MeasurementScheduleManage
> return;
> }
>
> - boolean enableDisable = (collectionInterval> 0);
> + boolean enable = (collectionInterval>= 0);
>
> // batch the modifications to prevent the ORA error about IN clauses containing more than 1000 items
> for (int batchIndex = 0; (batchIndex< measurementDefinitionIds.length); batchIndex += 1000) {
> int[] batchIdArray = ArrayUtils.copyOfRange(measurementDefinitionIds, batchIndex, batchIndex + 1000);
>
> - modifyDefaultCollectionIntervalForMeasurementDefinitions(subject, batchIdArray, enableDisable,
> + modifyDefaultCollectionIntervalForMeasurementDefinitions(subject, batchIdArray, enable,
> collectionInterval, updateExistingSchedules);
> }
> }
>
>
> _______________________________________________
> rhq-commits mailing list
> rhq-commits(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-commits
13 years, 6 months
Proposal: New Agent Communications
by Greg Hinkle
I've written up a proposal for a new Agent Communications System that I'd like to contribute for RHQ in the future. I'll start with not including the whole proposal in mail, but perhaps we can copy-paste any pieces you guys would like to discuss or comment on.
Executive Summary:
This new communication system, based on HornetQ, offers reduced configuration and deployment complexity, improved security and performance and a simpler, easier to maintain design. The biggest new features are unidirectional socket listening (server no longer needs to be able to open socket to agent), performance/scalability via nio/aio and simple to use SSL based authorization and encryption.
http://rhq-project.org/display/RHQ/Design+-+Agent-Server+Communications+3
It obviously isn't a small change to sneak in at the end of a release, but I do think it can be packaged into a fairly localized set of changes that can be managed in a branch until it's ready. Feedback welcome.
-Greg
13 years, 6 months
RfC: Test group separation / module reorganisation
by Heiko W.Rupp
Hi,
currently (nearly) all tests run in the integration.ejb3 group. No matter if those are server side plugins or core domain
or real biz logic.
Tests should imho be separated out in more distinct groups and only run if relevant
e.g. only run UI tests when UI code or code the UI depends on is changed, but not
when e.g. plugin code has changed.
Another aspect to this is that our builds often build a lot of stuff even if no relevant code
has been changed. THis is e.g. the case when a plugin is changed, the UI code needs
no rebuild (and vice versa).
It looks like the issue is not entirely trivial for the automatic testing side, but there is hope:
- http://www.dzone.com/links/sibilla_first_release_experince_a_new_approach...
that is by a colleague, Stefano Maestri and seems to analyze the relevant changed path
and only run relevant tests
- JunitMax ($$-ware) for Eclipse sorts tests according to runtime and likelihood of failing, so that
the user gets fast feedback and sees failures in the usual error view
Anyway : server side plugins should move out of enterprise/server to modules/server-plugins
installer should move out of the enterprise/gui into modules/installer and I guess there are
a few more candidates.
John Sanda was also proposing to move the performance testing outside of enterprise/server
into some (more or less) toplevel module.
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 6 months
re: fix for InventoryManager.mergeUnknownResources
by Joseph Marques
Mazz, good catch.
What is the next effect of this fix? I notice that size of the
'unknownResourceIds' collection is, in part, responsible for a
subsequent availability check and resource service scan. When the
collection size is incorrect - in the context of the larger inventory
synchronization process - what would the net effect of the previous
logic error be? Specifically, under what conditions would it trigger an
unnecessary availability check and service scan (false positive)? Under
what conditions would it miss them (false negative)? I'm satisfied by
inspection that this fix is correct, but I'd still like to know what
users (who lack the fix) would experience in terms of inventory
synchronization. On that note, shouldn't this be pushed to the latest
cumulative patch branch? Do you think this requires a BZ to track?
On 10/29/2010 04:57 PM, mazz wrote:
> modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java | 136 +++++-----
> 1 file changed, 73 insertions(+), 63 deletions(-)
>
> New commits:
> commit 7155896be74b82b2a9be7b1358103a4e2182fbcf
> Author: John Mazzitelli<mazz(a)redhat.com>
> Date: Fri Oct 29 16:52:44 2010 -0400
>
> we need to remove the disabled resource's IDs from the callers set - removing resources from our internal resource set is useless
>
> diff --git a/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java b/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java
> index 4c3b345..e483bb7 100644
> --- a/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java
> +++ b/modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java
> @@ -2449,7 +2449,7 @@ public class InventoryManager extends AgentService implements ContainerService,
> Set<Resource> unknownResources = configuration.getServerServices().getDiscoveryServerService()
> .getResources(unknownResourceIds, true);
>
> - Set<Resource> toBeIgnored = new HashSet<Resource>();
> + Set<Integer> toBeIgnored = new HashSet<Integer>();
>
> for (Resource unknownResource : unknownResources) {
> ResourceType resourceType = pmm.getType(unknownResource.getResourceType());
> @@ -2457,7 +2457,7 @@ public class InventoryManager extends AgentService implements ContainerService,
> mergeResource(unknownResource);
> syncSchedulesRecursively(unknownResource);
> } else {
> - toBeIgnored.add(unknownResource);
> + toBeIgnored.add(unknownResource.getId());
> if (log.isDebugEnabled()) {
> log.debug("During an inventory sync, the server gave us resource [" + unknownResource
> + "] but its type is disabled in the agent; ignoring it");
> @@ -2465,7 +2465,7 @@ public class InventoryManager extends AgentService implements ContainerService,
> }
> }
>
> - unknownResources.removeAll(toBeIgnored);
> + unknownResourceIds.removeAll(toBeIgnored);
> }
> return;
> }
13 years, 6 months
i18n of coregui.war
by Ian Springer
We plan to start this week on internationalizing the coregui webapp.
We will use the standard GWT i8n framework. The below wiki page
summarizes the steps for internationalizing a view or component and
lists a couple guidelines for the message bundle properties file.
Comments are welcome.
http://www.rhq-project.org/display/RHQ/GwtI18n
13 years, 6 months