testing HUD
by Charles Crouch
Further to the discussion on Friday afternoon around how to test HibernateDetachUtility, it doesn't seem to need an additional mock testing framework. I've attached a 17 line patch to HibernateDetachUtility which seems to do the trick of letting you swap out implementations of hash code generation. Also attached is HDUTest which is a 23 line (main method) test which at least according to my debugging, once TestHashCodeGenerator is being used, exercises during its execution all of the different code paths under:
} else {
// we have a situation where multiple objects have the same identity hashcode, work with our
// collision map to decide whether it needs to be scrubbed and add if necessary.
// Note that this code block is infrequently hit, it is by design that we've pushed the extra
// work, map, etc, involved for this infrequent case into its own block. The standard cases must
// be as fast and lean as possible.
...
}
Hopefully this could be useful in writing tests to confirm HibernateDetachUtility acts as we expect it to.
Thanks
Charles
12 years, 8 months
DiscoveryComponent only called once
by Till Essers
Hi,
I wrote a JON plugin that basically is a DiscoveryComponent and a
Component. The DiscoveryComponent extends the MBeanResourceComponent and
asks the MBean for the Components it should display.
Everything is working pretty fine except the fact that after the initial
discovery no new discovery is done.
So if there is something new the plugin should show, you can see it in
the JMX console but not in JON.
How can someone manually or programmatic make a new discovery of components?
With kind regards,
Till Essers
--
Till Essers
Softwareentwickler
Viada GmbH& Co. KG
Rheinlanddamm 201
D-44139 Dortmund
Phone: +49.231.28668.113
Mobile: +49.174.89567981
Fax: +49.231.28668.123
eMail: essers(a)viada.de
Web: www.viada.de
Viada-Quicknotes: www.viada.de/newsletter
Geschäftsführung: Michael Hadrys, Daniel Braunsdorf
Amtsgericht Dortmund, Registernummer HRA 16088
12 years, 8 months
[drift] working directly in master
by John Sanda
If there are no objections, I would like to start doing drift work
directly in master. While there is still a lot of work ahead of us,
things are stable enough that it should not cause major disruptions in
master. I feel like we've reached a point where working in a separate
branch has become a bit of a chore. Because things are more stable and
because I want to make things available for testing, I have been merging
back to master more frequently, and that is taking up more and more
time. Working directly in master means QE will be able to test things
sooner, one less hudson job to maintain, and QE automation will be
running against drift code more frequently. If we start to work on
things that may introduce instability then I propose we branch as necessary.
- John
12 years, 8 months
master test failure: RHQ Enterprise Server JAR
by Charles Crouch
Error Message
org/rhq/enterprise/server/drift/JPADriftServerBeanTest$1
Stacktrace
java.lang.NoClassDefFoundError: org/rhq/enterprise/server/drift/JPADriftServerBeanTest$1
at org.rhq.enterprise.server.drift.JPADriftServerBeanTest.initDB(JPADriftServerBeanTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:640)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:503)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:193)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:575)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:798)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1102)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121)
at org.testng.TestRunner.runWorkers(TestRunner.java:1009)
at org.testng.TestRunner.privateRun(TestRunner.java:683)
at org.testng.TestRunner.run(TestRunner.java:553)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:311)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:306)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:268)
at org.testng.SuiteRunner.run(SuiteRunner.java:217)
at org.testng.TestNG.runSuite(TestNG.java:1062)
at org.testng.TestNG.runSuitesLocally(TestNG.java:956)
at org.testng.TestNG.run(TestNG.java:874)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:61)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:144)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.lang.ClassNotFoundException: org.rhq.enterprise.server.drift.JPADriftServerBeanTest$1
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 32 more
12 years, 8 months
RHQ GUI: how to deal with user clicking to navigate to view X and then clicking to navigate to view Y before X has finished loading
by Ian Springer
How should the RHQ GUI deal with a user clicking to navigate to view X
and then quickly clicking to navigate to view Y before X has finished
loading?
This is a situation which we currently do not handle for the most part
in our GUI. There are a few places where when the user clicks on a
button on a list view, we disable the other buttons on the view until
the action for the clicked button completes. But, aside from this, the
user could still click on other links or buttons in the GUI either while
a server-side call is in progress or when the current view is still
being loaded/drawn. An easy way to see the variety of errors that can
occur as a result of such scenarios is to go to a Resource view and
quickly click on nodes in the tree and/or tabs or subtabs (a number of
BZs have recently been reported with such reproduction steps). Our
navigation infrastructure is simply not built to handle this. For
example, we have views that parse the current history token and assume
that token represents themselves, but if the user had already quickly
clicked on a link to go to another view, that assumption could be wrong
and a parse exception would occur.
There are a few ways we could deal with this issue:
1) ignore it, assuming that most of the time users will not click
something until the current view is fully rendered - this is bad because
users are used to being able to click something else if they change
their mind, and if a link or button is enabled, they assume they can
click it without causing application errors; such errors make RHQ not
look like a robust professional app
2) when a user clicks something, disable all other links and buttons on
the page until the action(s) initiated by the click have completed -
this would be very tedious to implement, and would probably require
adding a global handler that all links and buttons need to register
with; it could also annoy and frustrate users, because they would be
powerless to do anything else until the previously initiated action had
completed
3) when a user clicks something that will take them to another view,
display a "Loading..." message on the panel about to be updated, do all
of the drawing of the view off-screen, and only make it visible in the
panel once everything is fully loaded and drawn *and* a check that the
user hasn't navigated somewhere else succeeds; if the user clicks
something else, set some state to to tell other views that may still be
loading to not flip themselves to visible when they're done loading -
this would require a lot of refactoring across all our views, but at
least allows users to freely click around; it would also prevent them
from clicking on anything in the part of the page being updated until it
is fully drawn (this is similar to how SmartGWT ListGrids work - they
show a "Loading data..." message until the data is done loading and only
render the rows in the grid once the data is done loading)
4) re-architect coregui to use the MVP (Model-View-Presenter) pattern;
GWT 2.1 and later include the Activity and Place API which can be used
to do MVP-based navigation and bookmarking (see
http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlac...);
the API provides a clear separation between code that performs
navigation or some other action and code that actually draws a
widget/view, which allows something like 3) to be done easily and more
robustly
I think 4) is the best solution, because MVP is a pattern specifically
intended for large complex GWT apps like ours and would provide many
other benefits besides solving the issue at hand. The drawback is that
it would take a significant amount of work to rewrite the entire GUI
using MVP (I'm guessing 400-600 engineering hours). However, I think it
will save time in the long run, because it will make the app more robust
and maintainable. So I recommend we take the plunge. I think it could be
done as a new coregui2.war webapp within rhq.ear. This would allow the
latest business logic to gradually be pulled over from coregui.war as
parallel development goes on in coregui.war. Once coregui2.war is done,
coregui.war could be deprecated or deleted, and coregui2.war would take
its place.
If we decide we can't devote the resources to take on 4), I think 3)
would be the best option, but 3) would still be a lot of work (perhaps
200-300 engineering hours) and if we eventually do 4), it would all get
thrown away. If we don't want to do 4) or 3), then I would just go with
1), since I'm not a fan of 2).
Please give your thoughts on this. Which of the options do you think we
should take short term? long term? Are there are any other options you
can think of?
For a detailed description of the MVP pattern, read the two-part article
linked at the top of
http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlac....
Thanks,
Ian
12 years, 8 months
drift async job purges drift files
by John Mazzitelli
(this is probably only of interest right now for Jay and John S)
I checked in code that adds to the data purge job that runs hourly. We
now purge drift files if there are no drifts referencing it. Every hour,
when you see the data purge job emit its log messages, if you look in
there, you will see messages about purging drift files.
This means we can clean up and reclaim space for drift files that are no
longer used (that is, referenced as either an old or new file from any
drift entry).
This goes through the drift server plugin - if we are using the RHQ DB
backend, we'll purge unused rows in RHQ_DRIFT_FILE. I left a TODO in the
MongoDB plugin to do the purging when using MongoDB as the drift backend.
12 years, 8 months
TODO in ResourceFacets.initEnum()
by Ian Springer
Is it safe to uncomment the below line in ResourceFacets.initEnum() at
this point?
// TODO, add this back when we actually start storing drift config
templates:
// if (drift)
this.facets.add(ResourceTypeFacet.DRIFT);
I think it's what's causing the Drift tab to be visible for all Resource
types, rather than just the types that support drift.
12 years, 9 months
Re: Help with Drools JON/RHQ plugin
by John Mazzitelli
[I'm forwarding this to the rhq-devel mailing list - this is a good tech
discussion that should be made out in the open in the community]
Edson,
> In the end I was able to test the plugin by nuking the installation and re-installing after each change, as you suggested.
Nice - can you tell me which H2 files you had to restore? Was it just
one of those .db files or all of them?
> My questions are:
>
> 1. I would like to change it to make the plugin a top level server instead of running inside the JMX Server. Is it possible? How can I do it?
You can probably do this. In your plugin descriptor, just mimic what the
JMX descriptor has, tweeking as you need. In this case, you would not
need any "<runs-inside>" metadata.
You can probably reuse the JMX server component as well. Or at least
subclass it. Sounds like you want to override the discovery component so
it only detect things that has your MBean in it. So I would investigate
extending the JMX's plugin component "JMXDiscoveryComponent":
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/j...
Maybe write your own, or some how reuse the discover method:
org.rhq.plugins.jmx.JMXDiscoveryComponent.discoverResources(ResourceDiscoveryContext)
this method takes the process scan results (see the JMX plugin
<process-scan> for what its looking for in the operating system process
table - essentially it is looking for java executables). Sounds like you
want to do a little extra - you want to find all java VMs that have your
MBean in its platform MBean Server.
> 2. Related to above, I guess, how do I configure auto-discovery? My criteria is: any java process (JVM) that contains a DroolsManagementAgent MBean running should be discovered.
Right. See the JMXDiscoveryComponent class linked above for how you do
the first part. The JMX plugin is configured via <process-scan> metadata
to auto-discover java apps that are running. you'd then have to add your
own discovery code to look for whatever specific info you want to
further refine those results. In your case, you want to attach to that
java VM, peek in its platform MBeanServer and see if your MBean exists.
If it does, you'd return data for your discovered server. Otherwise,
you'd return nothing to indicate you found nothing.
> 3. I was able to configure all the metrics I want to collect, but how to I collect configuration data? I.e., things that were configured in the application and that rarely change, but that I want to keep track of and store as an historical audit trail in JON/RHQ. E.g. "Event Processin Mode = stream", "Assert Behavior = identity", "Max threads = 10".
Sounds like you want what we call a metric "trait". A trait is like a
metric but it can be any string (not just a double) and we track changes
to them over time (under the Measuerment tab, there is a subtab, I think
called "Traits"). It is assumed traits can change, but they change
rarely (less so then dynamic measurement data like "number of DB
connections" or "CPU utilization" or "free memory"). There are plenty of
examples of trait definitions in many of our plugins. See the agent
plugin or the jboss-as plugin or even the JMX plugin itself - look for
<metric> definitions that have dataType="Trait" attributes. One example
in the JMX plugin descriptor is:
<metric displayName="Heap Initial Size"
property="{HeapMemoryUsage.init}"
displayType="summary"
dataType="trait"
description="The amount of heap that the Java virtual
machine initially requests from the operating system"
units="bytes"/>
12 years, 9 months
long term scalability thoughts
by Charles Crouch
A paragraph from an unrelated email this morning helped solidify my thinking around where we could potentially end up going wrt to performance and scalability of RHQ...
"MongoDB, Membase, Memcache allow data flexibility and cloud scale. These are not old-sk00l Oracle databases that get slow with lots of data. These scale horizontally and are enabled by the scaling of a PaaS. We do of course have MySQL for the bits of data that aren't going to go through the roof. "
If users want to manage 1m metrics per minute, or 1m events per minute or 1m alerts per minute they are going to need N machines across which to scale the load. But at the same time there are probably going to be areas of the data model that just will never need to scale like that e.g. plugins, potentially the entire inventory (the requirements for reading/writing 1m resources could be very different to 30m *new* metrics every 12hours) and for that data something like a Postgres instance maybe sufficient. As long as we can also scale down the whole architecture to a single box for those people with smaller environments and still have a reliable and performant system.
BTW I'm not talking about making RHQ into a SaaS here or anything PaaS related right now. Just how to build a system that users could install on their own hardware that would scale in a close to linear fashion. e.g. If people want to manage an environment twice their current size, they call up Dell and order N more machines, set them up and install RHQ.
One further point, I think even if N can get quite large, I think users would still see that as a reasonable trade-off for near linear scalability (assuming that's achievable). If people have a really big environment they are more likely to invest in a larger monitoring/management infrastructure.
More thoughts please...
Thanks
Charles
12 years, 9 months
Move RHQ-sources to GitHub?
by Heiko W.Rupp
RHQ has been using Git for two years now with good success. Sources are "hosted" on
a reporitory at Fedorahosted, which is great.
Lately GitHub has seen a big uptake in awareness and also offers very nice features
like pull requests or easy forking of projects.
What is your opinion? Would moving to GitHub enable you to contribute more easily?
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
12 years, 9 months