This enhancement is to support the future ability to create alerts which compare metrics/triats against each other, as described in https://issues.jboss.org/browse/PRODMGT-95 and https://issues.jboss.org/browse/PRODMGT-31 this bz is *not* to add the metric comparison feature (that is covered in https://bugzilla.redhat.com/show_bug.cgi?id=582243) but just to add "max pool size" metric to the Datasource resource type. This new metric would then be used as part of a comparison. I don't feel strongly about whether the max pool size is collected as a metric or a trait. It seems more like a trait to me since its something which won't often change. But I'm unsure how alerting on comparisons of metrics and traits would work, given traits can be any datatype, i.e. you can't always compare a metric (double) to a trait (which could be a string for example). It may be simpler to just make max pool size a metric and just collect it every 24hrs for example (given its not expected to change frequently). Resource types upon which "max pool size" would need to be collected: EAP (JBASv7,v5,v4) and EWS (Tomcat6,5)
per scrum 1/23/2012 crouch, loleary, mfoley
This appears to already exist in jboss-as-5 plug-in but not in jboss-as plug-in.
This issue is blocked by https://issues.jboss.org/browse/JBPAPP-8169.
Updated to make this block the as7 plugin work. What's the approach for this now JBPAPP-8169 has been rejected?
So basically this looks like a misunderstanding between how the default values are defined for some objects in AS7. Instead of setting the default values in the object model itself as is the case in many places they are attaching a metadata description object where the default values are defined. This is not consistently done across all of the nodes or even the subsystems. In the AS7 administration console the default values are correctly displayed because they knew to populate the default values from the metadata(if undefined). I interpreted this as a bug when I requested the same data via cli and got undefined. In ER4.1 these values are available so this issue is no longer blocked.
There is no "maximum used pool size" metric, but a "max-pool-size" configuration entry, which can already be used for a future comparison feature. This config entry is even numeric. Adding this as a trait does (unlike Bug 791364) not really add value, as the value is already present (in Bug 791364 this required to run an operation on the server) Also as traits by default are strings they would need conversion to number before they could be compared. Charles, you really want the config value also be stored as trait?
Implement as a numerical metric that shows the configured max-pool-size which is collected once every 4 hours.
master 582a5d7
verified on AS7 plugin
Collecting max-pool-size starts failing on JON 3.1.ER6 + EAP6.ER8 this message seems to be related WARN [MeasurementManager.collector-1] (rhq.core.pc.measurement.MeasurementCollectorRunner)- Failure to colle ct measurement data for Resource[id=11302, uuid=b613d8d4-35cf-4073-b898-5f79f86769ce, type={JBossAS7}DataSource (Standalone), key=sub system=datasources,data-source=ExampleDS, name=ExampleDS, parent=datasources] - cause: java.lang.ClassCastException:java.lang.Integer cannot be cast to java.lang.String this is what CLI returns [standalone@localhost:9998 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size) { "outcome" => "success", "result" => big integer 555, "response-headers" => {"process-state" => "restart-required"} } 'big integer'
Result "big integer" looks strange as the type is defined as INT "max-pool-size" => { "type" => INT, "description" => "Das max-pool-size Element legt die maximale Anzahl von Verbindungen im Pool fest. Es werden nie mehr Verbindungen in Unter-Pools angelegt.", "expressions-allowed" => true, "nillable" => true, "default" => 20, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, And actually I can't even reproduce the cli output [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size) { "outcome" => "success", "result" => 2020 } [standalone@localhost:9999 /] /subsystem=web/connector=http:write-attribute(name=enabled,value=false) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size) { "outcome" => "success", "result" => 2020, "response-headers" => {"process-state" => "reload-required"} } Can you tell how to reproduce this "bigint state" ?
Not sure if that matters but I have installed both as7 and jdg plugins.
Looks like a bug in as7: https://issues.jboss.org/browse/AS7-4913
the "big int" thingy is a bug in as7. the class cast exception is a bug in my code. In addition, as7 used to require to wrap configuration changes to data sources into :disable / :enable pairs - this is no longer required and will throw errors in as7 console log [11:34:26] <pilhuhn> emuckenhuber The above is from a time where I had to disable a datasource to make config changes [11:34:35] <pilhuhn> emuckenhuber I think this is now gone? [11:35:30] <+emuckenhuber> pilhuhn: hmm, there was an issue about this recently [11:35:34] <+emuckenhuber> let me try to find it [11:36:19] <pilhuhn> Back in February I had to wrap the data source config change code in a disable/enable pair [11:38:48] <+emuckenhuber> yeah, now there is a header which will trigger that reload [11:39:08] <+emuckenhuber> however hbraun also had some issues last week with that - afair it was fixed upstream
master 918a99c02
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.