Attributes, metrics, additional descriptive information for such
by Brian Stansberry
Emanuel,
FYI I think this pretty much summarizes the various IRC etc discussions
today about metrics. Thoughts?
1) Metrics are represented in the model description at the same level as
"configuration" attributes.
2) Metrics are represented in a "read-resource" result the same as
configuration attributes.
3) Metrics are stored in a ModelNodeRegistration in the same map as
attributes
a) but they need to have a custom read handler registered, as the
default model-reading one won't work
4) Multi-server queries will not be done via the domain/host level
resources. This eliminates the "expense" issue of treating metrics
as attributes on a domain resource (expense due to need to read the
metrics across all servers in order to
generate the full result.) Instead, domain and host level resources will
not have metrics, and attributes will just return
the domain/host level value.
Instead, for multi-server results, wildcards and lists will be used:
e.g. host=*,server=*,subsystem=web,connector=http attribute=pool-size
e.g. host=[hostA,hostB],server=*,subsystem=web,connector=http
attribute=pool-size
e.g. server-group=group1,host=*,server=*,subsystem=web,connector=http
attribute=pool-size
e.g.
server-group=[group1,group2],host=*,server=*,subsystem=web,connector=http attribute=pool-size
This needs thought as to how to implement; sounds nice conceptually.
5) The model description for an attribute will include two additional
pieces of metadata:
storage (alternative term -- applies-to): Either
configuration = Derived from and stored in the persistent configuration
(i.e. domain.xml/host.xml/standalone.xml).
runtime = Derived from and stored in runtime state only, and not in any
persistent configuration.
There's an ongoing debate over "storage" vs "applies-to".
access-type: One of
read-only = Not modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
read-write = Modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
metric = Value may change without any management action. Not directly
modifiable via a management action.
6) The value for said "storage" and "access-type" fields in the
attribute description will be generated by the
READ_RESOURCE_DESCRIPTION operation handler. It will not come from the
resource's DescriptionProvider (i.e. we
don't rely on developers correctly adding this metadata for each attribute.)
TBD:
1) "storage" vs "applies-to"
2) How to ensure the "storage" and "access-type" fields are correctly
set? Likely replace/overload ModelNodeRegistration's
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler);
with
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler, Storage storage);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler, Storage storage);
void registerMetric(String attributeName, OperationHandler readHandler);
2) We briefly touched on the concept of a "runtime entity" aka a
"runtime resource". A resource that
only exists in the registry, but has no persistent representation in
domain.xml,
host.xml or standalone.xml.
a) Said runtime resource cannot have attributes with storage=configuration
b) We briefly mentioned having recursive model reads stop at runtime
resources, in order to avoid excessive cost.
3) If we have runtime resources, this status should probably be
reflected in the resource description.
And probably should be stored directly in the ModelNodeRegistration,
e.g. via
ModelNodeRegistration registerSubModel(PathElement address,
DescriptionProvider descriptionProvider, Storage storage);
4) Does storage/applies-to have a 3rd value: "both"? IOW does
"configuration" always imply "runtime"?
5) The "storage/applies-to" concept is relevant to operations in
general, not just reads/write of attributes.
6) We need to know whether execution of an operation (including
write-attribute) on a server puts that server
in a state where it requires a restart. If the operation will always
trigger a restart requirement, we use
the interface implemented by the handler for the operation to determine
this. Some operations may or may
not trigger a restart requirement; it depends on the value of the
parameters and the current state when
they are applied.
Clients are likely to want to know about the restart impact before
executing an operation (i.e. if it will/may/won't
trigger the need to restart). So this should be added to the
operation/attribute description.
7) Some operations can be applied to the runtime even if a previous
operation has triggered the requirement
for a restart is required. Some may always work, some may or may not
work depending on the params and
the runtime state. We currently have no mechanism for informing the
server controller of this kind of thing;
we just disable all runtime updates once restart is required. It would
be better to make this information
available to the server controller. Clients may want to know as well, so
this should be added to the
operation/attribute description.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 1 month
Maven Repository Dependencies
by Darran Lofthouse
I was speaking to David yesterday and said I would raise a thread to see
if there is a consistent approach that could be used for defining which
repositories to use to download the dependencies for JBoss AS and the
other smaller components.
Personally I have had problems in the past trying to work with a single
central configuration for repositories so I have been trying to avoid a
central configuration as much as possible.
For the actual AS build the repositories have been defined in the
pom.xml so I was proposing a similar change for other modules that
require some dependency from our Nexus repos e.g.
https://github.com/darranl/jboss-dmr/commit/3b47d97410cdfd25845f1ff2399e1...
Does this make sense for all the smaller projects where required or do
we still want changes to be made to a local settings.xml just to be able
to build?
Regards,
Darran Lofthouse.
14 years, 1 month
detyped checkstyle errors
by Scott Stark
I'm trying to rebuild the detpyed branch of
https://github.com/bstansberry/jboss-as.git, and I'm seeing this fail
due to checkstyle errors when building the jboss-as-domain-client
project. Is this legit or something out of date in the build env. I have
not built on this particular box for a while, so perhaps there is some
older mvn pieces around.
[INFO] Compiling 78 source files to
/Users/git/detyped/domain-client/target/classes
[INFO]
[INFO] --- maven-checkstyle-plugin:2.5:checkstyle (check-style) @
jboss-as-domain-client ---
[INFO] Starting audit...
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:110:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:132:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:142:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:153:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:160:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:189:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:198:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:110:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:132:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:142:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:153:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:160:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:189:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:198:5:
Redundant 'public' modifier.
Audit done.
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: Build Configuration ..... SUCCESS [2.289s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [1.603s]
[INFO] JBoss Application Server: Protocol Utilities ...... SUCCESS [3.132s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [13.357s]
[INFO] JBoss Application Server: Domain Client ........... FAILURE [1.439s]
[INFO] JBoss Application Server: Domain Client ........... SKIPPED
...
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 23.618s
[INFO] Finished at: Mon Jan 31 12:42:02 PST 2011
[INFO] Final Memory: 38M/104M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.5:checkstyle
(check-style) on project jboss-as-domain-client: An error has occurred
in Checkstyle report generation. Failed during checkstyle execution:
There are 14 checkstyle errors. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :jboss-as-domain-client
14 years, 1 month
Descriptions of non-simple attributes
by Kabir Khan
For jboss-as-threads I wrote pretty full model descriptors, however for values such as
<keepalive-time time="100" unit="ms"/>
I split this into two attributes in the model
node.get(ATTRIBUTES, KEEPALIVE_TIME_DURATION, DESCRIPTION).set(bundle.getString("threadpool.common.keepaliveduration"));
node.get(ATTRIBUTES, KEEPALIVE_TIME_DURATION, TYPE).set(ModelType.LONG);
node.get(ATTRIBUTES, KEEPALIVE_TIME_DURATION, REQUIRED).set(false);
node.get(ATTRIBUTES, KEEPALIVE_TIME_UNIT, DESCRIPTION).set(bundle.getString("threadpool.common.keepaliveunit"));
node.get(ATTRIBUTES, KEEPALIVE_TIME_UNIT, TYPE).set(ModelType.STRING);
node.get(ATTRIBUTES, KEEPALIVE_TIME_UNIT, REQUIRED).set(false);
//threadpool.common.keepaliveduration=Used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down.
//threadpool.common.keepaliveunit=The time unit for the number specified in keepalive-time-duration.
Working on the marshalling I see Emanuel takes a different approch by passing in simple sub-elements like this as a ModelNode which is more elegant. That is kind of what I wanted to do but didn't really know how to write the description in a nice way. Since there are not many descriptors yet I'd like to clarify the structure and find the best practice. My original thought was that the structure would have to go in the node's description attribute (ATTRIBUTES, KEEPALIVE_TIME, DESCRIPTION below), but it might be nicer to do something like this:
node.get(ATTRIBUTES, KEEPALIVE_TIME, DESCRIPTION).set("Used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down"));
node.get(ATTRIBUTES, KEEPALIVE_TIME, TYPE).set(ModelType.OBJECT);
node.get(ATTRIBUTES, KEEPALIVE_TIME, REQUIRED).set(false);
node.get(ATTRIBUTES, KEEPALIVE_TIME, TIME, DESCRIPTION).set("The time"));
node.get(ATTRIBUTES, KEEPALIVE_TIME, TIME, TYPE).set(ModelType.LONG);
node.get(ATTRIBUTES, KEEPALIVE_TIME, TIME, REQUIRED).set(false);
node.get(ATTRIBUTES, KEEPALIVE_TIME, UNIT, DESCRIPTION).set("The time unit (Seconds, Milliseconds etc.)"));
node.get(ATTRIBUTES, KEEPALIVE_TIME, UNIT, TYPE).set(ModelType.STRING);
node.get(ATTRIBUTES, KEEPALIVE_TIME, UNIT, REQUIRED).set(false);
And if the keepalive-time attribute is optional but if present both time and unit sub-attributes must be specified, I think we would go with something like
node.get(ATTRIBUTES, KEEPALIVE_TIME, REQUIRED).set(false);
node.get(ATTRIBUTES, KEEPALIVE_TIME, TIME, REQUIRED).set(true);
node.get(ATTRIBUTES, KEEPALIVE_TIME, UNIT, REQUIRED).set(true);
If it is keepalive-time is required and unit is optional, how about
node.get(ATTRIBUTES, KEEPALIVE_TIME, REQUIRED).set(true);
node.get(ATTRIBUTES, KEEPALIVE_TIME, TIME, REQUIRED).set(true);
node.get(ATTRIBUTES, KEEPALIVE_TIME, UNIT, REQUIRED).set(false);
14 years, 1 month
Documentation of Management Operations
by Heiko Braun
Can we create a WIKI space that documents existing managed operations?
Will it possible to get some HTML docs? Or would I need to read every subsystem java code in order
to figure out what managed op's and attributes are available?
Ike
14 years, 1 month
Management Console JDK Server Example
by Jason T. Greene
Previously I mentioned the possibility of a console so lightweight that
it can be included inline on the DC process.
I threw together a basic example in a few minutes that demonstrates how
a GWT->JSON application (using the GWT JSON sample) can be trivially
served up via the JDK http server API with barely any overhead.
http://community.jboss.org/servlet/JiveServlet/download/16363-1-24960/emb...
Source:
http://community.jboss.org/servlet/JiveServlet/download/16363-3-24962/Res...
Just do java -jar embedded-demo.jar, and go to http://localhost:8000.
Our management console architecture could follow a similar approach. We
would have both the REST/JSON Domain API and console collected in the
same DC JVM. The console would then just be static content
(javascript/html) that issues the proper JSON requests via HttpRequest.
It's also possible to do GWT-RPC this way, but that would essentially be
adding an extra layer, which is likely not needed. In both cases we
would be shifting state to client, which saves resources.
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 1 month
HTTP API: Availability
by Heiko Braun
When will the HTTP API be available?
It's one of the higher priority items for the management console.
Ike
14 years, 1 month
i18n
by Heiko Braun
I was just looking at the example how to retrieve the resources descriptions for the current domain model tree.
(See Brain earlier post). Many of the resources contain complete and meaningful description attributes. (Well done.)
I cannot see, wether or not these attributes are served from a localized bundle, but I want to remind everybody
to build for i18n upfront. We expect the management UI to support different locales early in the game, to ensure things work properly on the UI side of things. If you could the prepare the modules you are working on accordingly, it would be a great help.
Ike
14 years, 1 month
