Need advice about agent plugin design
by Steven North
I am trying to design an RHQ/JON agent plugin to manage a software
resource with the following characteristics:
- there is the software itself (the installation);
- there are a variable number of "bundles" of configuration information
about 250KB in size each which need to be read from and written to the
agent; and
- there are "log" files which can 10-50MB in size each which need to be
read from the agent.
I think I am pretty clear on how to handle the software itself--just
like any number of other agents.
I am not sure how to handle the configuration bundles and the large log
files.
We might want to have the RHQ/JON server manage different versions of
these configuration files and distribute them to multiple remote agents.
Is there some existing domain object that would handle the read/write
aspect of the configuration bundles (zip files)? Could the "package"
concept be used for these? Would we need to create a new domain object
on the server side for these bundles? If so, is there an example of
this kind of thing?
For the log files, I see some mention of the SupportFacet. Would this
be appropriate for retrieving large log files? Is there an example of this?
We expect to access the configuration bundles and the log files using
remote client operations because we have a separate GUI tool to
build/edit the configuration bundles and to correlate and analyze the
log files. Is there an example of using a remote client to pull files
from and push files to remote agents?
Thanks in advance for any advice you can give or examples you can point to.
Steve
10 years, 1 month
MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)
by Jiri Kremser
Hi,
in plugin descriptor, there can be a metric definition with unit type "epoch_milliseconds" or "epoch_seconds" (rhq-configuration.xsd allows it). What kind of metric should could be represented by epoch_milliseconds? Shouldn't the exact time moments (what values epoch_milliseconds represent) be addressed rather by traits?
I am asking because the values of this type are not formatted (https://bugzilla.redhat.com/show_bug.cgi?id=857144).
I think these two unit types should be removed from MeasurementUnits and xml schema, however there might be some plugins out there using it, so what about deprecation? Are there any edge cases, when these unit types do make sense?
JK
10 years, 2 months
Bug 887320: OutOfMemoryError when adding new Deployment child resource on AS7
by Thomas Segismont
Hi all,
I'm writing to you about this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=887320
For those not aware of it, an OutOfMemoryError is raised on the agent
when you try to add a child resource of type deployment to a managed AS7
instance.
It happens because the AS7 plugin uses HttpUrlConnection to communicate
with AS7 HTTP management interface.
Basically, HttpUrlConnection waits for the request payload to be fully
loaded in memory before it tries to contact the server. It does that to
be able to resend the request payload if the server ask for redirection
or start an authentication challenge.
While this is acceptable for small payloads, it's not suitable for large
file uploads (in our case a 42M WAR upload triggers the OutOfMemoryError).
For large file uploads, HttpUrlConnection provides a streaming mode. But
in streaming mode it does neither support redirection nor
authentication. I tried to use streaming mode to make a fix yesterday
and it's really not working (BTW, sorry for the patch revert waltz).
I can see two options:
#1 Keep HttpUrlConnection as communication layer
In this case, the streaming mode is mandatory. This means we should
maintain our own authentication challenge code and set authentication
headers manually.
#2 Use HttpClient as communication layer
Personally, I prefer #2
Importing HttpClient in AS7 plugin will increase the plugin
dependencies list. But I think it's a small price to pay compared to the
efforts we would spend maintaining our own authentication and
redirection code.
What do you think?
Thanks
Thomas
11 years, 3 months
Purging the agent's security token
by Jiri Kremser
Hi,
I would like to implement this feature Jay originally proposed. The idea is that it should be possible, for the authorized user (MANAGE_SECURITY), to invalidate an existing security token for any reason (mostly agent/db upgrade). Invalidating the token means setting its value to something like @#$reset$#@, and storing it to the DB for an agent with name "A". Next time the agent "A" tries to register, server finds out the token in the DB is willing to be updated with the agent's actual token. And stores it into DB instead of temporary marker "@#$reset$#@".
There are still some questions to discuss:
1) When clicking on the button for purging the existing token, should be the agent disconnected/reconnected or is it ok to continue in this quite undef state?
2) Are there any edge cases in this approach? For instance if attacker provides -Drhq.agent.security-token=@#$reset$#@ on purpose (this can be easily handled).
3) Possible race condition when registering the different 2 agents with the same name when the token is invalidated for this name.
..
Here is the BZ for it https://bugzilla.redhat.com/show_bug.cgi?id=888016
JK
11 years, 3 months
Warning: about to remove jon3.1.x branch (not release/jon3.1.x)
by Thomas Segismont
Hi all,
A jon3.1.x branch has been incidentally created in the FedoraHosted Git
repo and can lead to confusion with release/jon3.1.x branch.
I'm going to delete it very soon so if you have any concern, please tell me.
Thanks and regards
Thomas Segismont
11 years, 4 months
test execution times
by John Sanda
On Friday I went to execute MeasurementDataManagerBeanTest, which is now in the server/itests-2 module. I was unpleasantly surprised by the execution time. Running this,
$ mvn -o clean test -Dtest=MeasurementDataManagerBeanTest
was taking upwards of 50 seconds. I am running on a fast machine as well so I imagine the situation only gets more bleak on slower hardware. There is nothing crazy going on in MeasurementDataManagerBeanTest to cause such a long build time. I need to write more tests, but I consider this is a blocker. The problem has to do with Arquillian, or more specifically, how we are using it. In a local branch I did some prototyping using AuthorizationManagerBeanTest, for reasons I will explain later, and was able to get the execution time down to about 10 seconds. There are a few things I did to bring down the execution time.
1) Do not redeploy AS 7 every test run.
Even when not doing a clean, I was still seeing 40+ second build times. Simply commenting out the antrun plugin in pom.xml sped things up a little bit. We could put that plugin in a profile so we are not always executing the Ant script(s) to deploy our AS 7 server. I do something similar with Cassandra tests.
2) Use remote container instead of managed container
Arquillian handles starting and stopping a managed container whereas the lifecycle of a remote container is not handled by Arquillian. I kept my AS 7 instance running. Maybe Jay and/or Mazz have some insights into whether or not there might be issues with using a remote container.
3) Introduce more modularity
I studied the timestamps in the log statements of tests runs to get a better feel for where the most time is being spent. While there is not one huge culprit, the lack of modularity is a big problem, and it will only get worse. We have lots of EJBs, and they are split across only 2 EJB JAR files. One contains entity beans, and the other contains all of our SLSBs and MDBs. The latter corresponds to the very large server/jar module. When you go to run an Arquillian test, we deploy all of those EJBs along with some other components. Given the sheer number of them, it is going to take some time for the deployment to run.
In order to speed up deployments and execution times, we need to limit what we deploy to test code, the production code under test, and required runtime dependencies. This however is not possible with the source code organized and packaged as it is. In my branch I chose AuthorizationManagerBean because of its minimal dependencies. It minimized the amount of refactoring I had to do to get things running. I created a new module named server-authorization that produces an EJB JAR artifact. My test produces/deploys a JavaArchive much like the example at http://arquillian.org/guides/getting_started_rinse_and_repeat/.
Modularizing our EJBs makes the build more complex, but it brings a lot of benefits. Prior to the AS7 merge to master, SLSBs along with tests lived in server/jar. I rarely would execute all of the tests in server/jar because of how long they take to run. Even running a single test class took a non-trivial amount time due to the embedded container start up/initialization time. Now consider the process with our Arquillian set up. Suppose I make a change to MeasurementDataManagerBean that I want to test. Here are the steps,
Make code changes to MeasurementDataManagerBean and to MeasurementDataManagerBeanTest
mvn install server/jar
mvn install server/ear
mvn test -Dtest=MeasurementDataManagerBeanTest (from tests-2 module)
In addition to the already very long running time for the test, I have to rebuild both server/jar and the EAR. With what I have done, both MeasurementDataManagerBean and MeasurementDataManagerBeanTest might live in a module named server-metrics. The steps to test some changes would be as follows,
Make code changes to MeasurementDataManagerBean and to MeasurementDataManagerBeanTest
mvn test -Dtest=MeasurementDataManagerBeanTest
There is no need to rebuild any other modules and the test presumably will execute a lot faster as we only deploy the required artifacts instead of the whole EAR. There are more benefits to increases modularity, but I will postpone those to a later email since this has one has already gotten rather length.
- John
11 years, 4 months
First ALPHA of RHQ 4.6 available
by Heiko W.Rupp
Hello,
we have published a development snapshot of the new RHQ 4.6 release stream as the first
alpha version of RHQ 4.6
THIS IS NOT FOR PRODUCTION
Notable changes are
* RHQ now runs on top of JBoss AS 7.1 instead of the old AS 4.2.3
* GWT has been upgraded to 2.5
* There is a new installer, written in GWT
You can get the release from sourceforge, where a README file also describes how to use the installer.
https://sourceforge.net/projects/rhq/files/rhq/rhq-4.6.0-alpha/
Please help us identify and fix issues
Again, this alpha is not for production use.
Heiko, on behalf of the RHQ team.
--
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: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 4 months
jboss as7 inconsistent expression support
by John Mazzitelli
forwarding from the jboss-as7-dev mailing list - I've noticed (and wrote some JIRAs) on AS7.1.1.Final not supporting expressions where I think they should (or where they have in the past with AS 4 config settings).
Looks like they are trying to open it up so the vast majority of attributes accept expressions (at least, that's how I interpret this thread).
----- Forwarded Message -----
From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Friday, December 14, 2012 2:20:58 PM
Subject: Re: [jboss-as7-dev] inconsistent expression support
I see 4 levels to this:
1) Convert resources from the coding pattern we had in 7.0 to properly
use ResourceDefinition/AttributeDefinition. There is only a small bit of
this left to do, and any addition of expression support we're doing for
7.2 is being done in the context of this kind of conversion. There can
still be mistakes made using RD/AD, as AS7-6154 shows, but I believe
this conversion has decreased the likelihood of bugs a *lot*.
2) The basic subsystem tests that Kabir describes, based on
AbstractSubsystemBaseTest. Every subsystem should have one of these that
tests an example config that covers all configuration elements and
includes expressions for all items where they are supported. I think the
coverage of these is inadequate, but they are really, really easy to add
-- just create some xml and add a 1 line test method.
We'll be adding these where missing between now and Jan 8. If you are a
developer on a subsystem where this coverage is inadequate, please ping
me, Tomaz Cerar, Kabir Khan, Jeff Mesnil or Emanuel Muckenhuber and
*volunteer to do this*.
This will cover the round-trip from XML to model and back, which is
roughly 2/3rds of the problem space.
That leaves the runtime part, ensuring that operation step handlers are
properly using AttributeDefinition.resolveModelAttribute(context,
operation). As Kabir noted, it's harder to unit test these because most
runtime handlers set up services that require complex dependencies.
3) What I'm looking to do for runtime is to start up a host controller
in admin-only mode using our standard domain.xml. Then iterate through
all resources, looking for read-write attributes that support
expressions. Invoke the write-attribute op to set an expression. Then
reload and confirm that all servers start cleanly. This will cover a big
chunk.
4) Covering the rest is going to require people updating their
AbstractSubsystemBaseTest to also cover runtime, as Kabir described. I
expect this will be a slow process, not something we'll do much on in
the next few weeks.
But I think the combo of 1, 2 and 3 will leave us in better shape than
we were in the 7.1 series.
On 12/13/12 10:08 AM, Kabir Khan wrote:
> One problem is that AbstractSubsystemBaseTest, out of the box, just tests the MODEL part, and not the RUNTIME part of the operation handlers, and quite often these problems only appear in RUNTIME. It is little used but subsystem-test allows you to test the RUNTIME part as well, an example is in ModelControllerMBeanTestCase which installs the other parts of the model, extra services and other bits and pieces required for the subsystem's runtime to work in its ModelControllerMBeanTestCase.BaseAdditionalInitialization. There are also some examples in subsystem-test itself, and might be others in other subsystems. Of course, for some subsystems there might be quite a lot to set up which is why I've not been stricter about this.
>
> To 'improve' the affected tests using AbstractSubsystemBaseTest to also cover runtime, one can override AbstractSubsystemBaseTest.createAdditionalInitialization() to return a proper setup for services to run. Although since that starts three controllers, which might cause port conflicts, it might be better to use something more similar to what ModelControllerMBeanTestCase does, which extends AbstractSubsystemTest directly.
>
> On 13 Dec 2012, at 15:46, Jeff Mesnil wrote:
>
>> On 12/13/2012 09:56 AM, Heiko Braun wrote:
>>>
>>>
>>> opening up the configuration to support expressions all over the place is desirable, but I wonder how far away we are from actually supporting it. We've been very restrictive in the console with using expressions, now we support it by default on all attributes. This is what happens:
>>>
>>> https://issues.jboss.org/browse/AS7-6154
>>>
>>> I wonder how we can actually verify full expression support, apart from simply declaring support in the meta data. IMO it would require to iterate over the current stock config and replace all occurrences of attributes that declare support for it with a default expression.
>>
>> That's what I did for the messaging subsystem. I used expressions in the subsystem XML tests for every attributes that are now
>> allowing them.
>> I found a few bugs like yours doing that but that was not enough.
>>
>> Another thing was to check during XML parsing for STRING attributes. Some have their value set and not parsed using
>> AttributeDefinition.parseAndSetParameter() or ParseUtils functions. This results in a STRING ModelType (a literal
>> "${exp:default}") while it must be an EXPRESSION instead.
>> I had also to fix a few calls at runtime where the attribute value was not fetched using
>> AttributeDefinition.resolveModelAttribute() and the expression was not resolved.
>> These errors occurs at runtime and were easy to miss (I may not have found all of them).
>>
>> jeff
11 years, 4 months