2nd level cache monitoring
by Francesco Marchioni
Dear all,
does anyone know if it will ever be possible to monitor the 2nd level cache
(basically its size) through the CLI/web interface ?
At the moment I'm using a programmatic approach (with HibernateStatistics)
however I'm looking for an admin approach to it.
Thanks a lot
Francesco
14 years, 11 months
JBoss Modules documentation
by Vimal Kansal
Hi Folks,
I am going through the various documents that are being created for AS7.
I realised that, JBoss Modules has still many pieces undocumented and
was last updated in Jun. So far the document is looking simply great.
Can somebody please take time to fill in the missing bits.
Thx
Vimal
14 years, 11 months
How should META-INF/services be dealt with in modules?
by Scott Stark
So I have been looking at what the minimum is for a reasteasy based war
to work with an application/xml content type since the providers for
that are bundled in the as7 modules, but the providers are not getting
registered by default. The war does not include any of the resteasy jars
in its WEB-INF/lib as it looks like everything should already be
included in the as7 modules.
In order for this to work, I have to register all of the
javax.ws.rs.ext.Provider annotated classes from the
resteasy-jaxb-provider-2.1.0.GA.jar in my resteasy Application:
import javax.ws.rs.core.Application;
public class StatusApplication extends Application {
@Override
public Set<Class<?>> getClasses() {
Class<?>[] classes = {
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlRootElementProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBElementProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlTypeProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.CollectionProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.MapProvider.class,
org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.class
};
for(Class<?> c : classes)
providers.add(c);
return providers;
}
Normally resteasy is expecting that it can locate these via the jar
META-INF/services/javax.ws.rs.ext.Providers mechanism, but when the
resteasy framework does the following call while processing the application:
Enumeration<URL> en =
Thread.currentThread().getContextClassLoader().getResources("META-INF/services/"
+ Providers.class.getName());
all it sees is the
resteasy-jaxrs-2.1.0.GA.jar/META-INF/services/javax.ws.rs.ext.Providers
resources. It looks like many of the other resteasy provider modules
would not be loaded simply because they are purely extension modules
with implementations.
What is the correct way to integrate a collection of services using the
META-INF/services mechanism?
14 years, 11 months
Review process nomination
by Carlo de Wolf
Hello people,
I would like to nominate Jaikiran as reviewer/pusher on the jboss-as
repository.
Please let me know if there are any objections.
Thanks,
Carlo
14 years, 11 months
Platform MBean visibility via the AS7 management API
by Brian Stansberry
Jason has pushed my patch that provides $subject. [1]
Platform mbeans are available on a standalone server under resource:
/core-service=platform-mbean
For a Host Controller JVM, they can be found at:
/host=<host name>/core-service=platform-mbean
For a Server in a managed domain, they can be found at:
/host=<host name>/server=<server name>/core-service=platform-mbean
The resource at the addresses above is really just a placeholder; the
actual mbeans are exposed via child resources. The names of the child
resources follow a pattern based on the ObjectName of the underlying mbean:
/core-service=platform-mbean/type=class-loading
/core-service=platform-mbean/type=memory-pool/name=<escaped pool name>
The "type" and "name" child types match the keys in the standard
platform mbean ObjectName properties. The values for the 'type'
attribute are the same as the ObjectName values, but converted to match
standard domain management API resource name standards:
1) All lower case
2) A '-' used to separate words where the ObjectName preoperty value
would use CamelCase.
ClassLoading -> class-loading
MemoryPool -> memory-pool
The value of the "name" property in a platform mbean depends on the
runtime platform; it is not known in advance. I did not attempt to
convert this portion of the platform mbean names to lower-case with '-'
separator convention. The <escaped pool name> above refers to the fact
that the ObjectName for some mbeans may includes spaces in the value of
the "name" key. Spaces are not valid in resource addresses, so any
spaces have been replaced with the '_' character in the address.
See [2] for the full list of resource names.
Note that the attributes and metrics exposed by these resources are
"runtime" attributes; i.e. they are not directly stored in any
persistent configuration. The handlers for the standard "read-resource"
and "read-children-resources" operations will not include "runtime"
attributes in a result unless parameter "include-runtime" is provided
with value 'true'. So be sure to include that parameter when trying to
read these resources, or you will be a successful but receive an empty
result.
The MBean attributes of the platform mbeans are exposed as resource
attributes. The operations are exposed as operations with the same
parameters. The attribute, operation and parameter names are the same as
what is found in the JDK javadoc for the relevant mbean, except the
CamelCase to lower-case with '-' separator conversion is followed
throughout.
The only place where an attribute, operation or parameter name should
vary from the JDK name is with the ThreadMXBean's getThreadInfo method.
Some overloaded variants of that method return an array, some a single
value. The domain management API does not support multiple return value
types from an operation with the same name. So, the operation for the
overloaded variants that return a single value is 'get-thread-info'
while for the variants the return multiple values the operation is
'get-thread-infos'.
[1] https://issues.jboss.org/browse/AS7-340
[2] The platform mbean names on a standalone server are listed below.
Names are the same for managed domain processes, except they are
prefixed as described above.
/core-service=platform-mbean (placeholder resource)
++ type=buffer-pool (JDK 7 only; placeholder resource)
++++ name=<dynamic> (JDK 7 only)
++ type=class-loading
++ type=compilation
++ type=garbage-collector (placeholder resource)
++++ name=<dynamic>
++ type=logging (JDK 7 only)
++ type=memory
++ type=memory-manager (placeholder resource)
++++ name=<dynamic>
++ type=memory-pool (placeholder resource)
++++ name=<dynamic>
++ type=operating-system
++ type=runtime
++ type=threading
The "placeholder resources" above do not expose any attributes or
operations other than the global operations. They are placeholder nodes
in the resource tree.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 11 months
Important 7.0 branch
by Jason T. Greene
I am going to be creating a 7.0 branch, and I am going to attempt to
merge everything that has a fix-for version of 7.0.2 on it that is
resolved. After that I am going to need a different pull request on the
7.0 branch for any 7.0.x fixes.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years, 11 months
JMX Facade
by Kabir Khan
The ongoing work for the JMX facade to the management model lives here: https://github.com/kabir/jboss-as/commits/jmx-facade
I'm still working through a few things before this is complete. I've included a description of how this works, along with some assumptions, things I came across when doing this and some questions.
To set up the management mbean stuff, I have added an optional element called 'show-model' to the jmx subsystem:
<subsystem xmlns="urn:jboss:domain:jmx:1.0" show-model="true">
<jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
</subsystem>
The default value is 'false', do I need to bump up the schema version number in this case (it is backwards compatible). If 'true' I wrap the mbean server in a similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are actually created.
In brief how it works is that every resource in the model has an associated MBean in the 'jboss.model' domain , so for example '/subsystem=jmx' becomes 'jboss.model:subsystem=jmx'. All MBeans are described using OpenMBeanInfo.
The resource attributes become attributes on that mbean, and operations become operations on that mbean. An exception to the operations are the standard 'add' operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the 'add' method lives on the parent MBean instead, so you would invoke the 'add-child' operation on 'jboss.model:subsystem=foo'.
The root of the model is registered under 'jboss.model:type=root'.
The types of attributes and operation parameters are defined using the open mbean types. For simple attributes where 'type=INT', that becomes an open mbean SimpleType.INT and so on. More Complex types are also handled, for example;
* {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where the element type is SimpleType.STRING)
* {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType, where the index is called 'key' and each entry is a CompositeData containing the key under 'key' and the value under 'value'.
* Complex objects, such as {type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a CompositeData where 'one' has the type SimpleType.STRING and 'two' has the type SImpleType.INT.
I still have to handle ModelType.PROPERTY, I left that until the end - I think this will become a CompositeData. I still need to look where PROPERTY is used in the model and see if we need to force those to have a VALUE_TYPE or if String can be assumed.
I am not inheriting any of the global operations at the moment (read-attribute, read-resource-description etc.), and am not sure if it makes to include them even in 'jboss.model:type=root' since they are detyped model specific, most of the information from these ops is available in other ways via jmx. I still need to verify that all mbeans can be described in AS, but I've already seen that these global ops need some work to get them to work since the root mbean fails on those.
I am not doing anything to handle operations that have more than one REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
I noticed one thing when using jconsole. If you attach to a 'local' process we never hit my management model wrapper or TcclMBeanServer, that only happens if you connect to localhost:1090 so it comes in via the connector. I need to look at this part of the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so that the behaviour always is available.
I am not allowing notification listeners to be registered under 'jboss.model:'. It might be possible to add another configuration persister to trap these events, but since (I think) we only really know if the model has changed or not, not what has actually changed, I think that would add overhead at the moment until notifications are added to the core management model.
I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query) or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
Due to jmx using 'proper' method signatures where the order of the operation parameters is important, and the detyped management model using request-properties keyed by name, if the management model changes the order of parameters between releases jmx clients will break.
14 years, 11 months
Passing Cloud Configuration.
by Robb Greathouse
Hi,
We are putting JBoss 5.1.1 into the Amazon EC2 cloud. There are some peculiarities of how EC2 wants to configure instances that we are running into.
EC2 wants to use a standard AMI - basically a standard image that anyone wanting to use JBoss would use. They would then customize this image by passing parameters via a single user-data file.
While the user could ssh into the instance once it is started and manually change the settings; this is not considered user friendly.
Ideally, we would like to be able to pass any configuration variable via user-data. These would include database settings, clustering settings, etc.
Robb,
--
--
14 years, 11 months
Management proposal for attribute mutability
by Jason T. Greene
Currently we have way too many read only attributes in our management
model. This makes life harder for the management tools and/or makes the
resulting UI a bit unwieldy.
In some cases this is just because we haven't polished subsystem
management (PLEASE all subsystem authors look at this!). In other cases
though it's intentional because it is either difficult or currently
impossible to make hot changes to a particular attribute. This should be
exceedingly rare. Users love hot updates, and it's a competitive
advantage. So first we should strive to make it hot in the first place.
However in the case that the change is not hot, and a server reboot is
too aggressive, we should still supporting making the changes by
bouncing all services involved. After some debate on IRC we finally
arrived at what is IMO a really good option for this problem:
write-attribute (impact-services=true|false)
The operation handler on such a non-hot attribute would then return an
error if false (the default), but would continue and bounce everything
needed if the value is true. In addition we would add some simple
description metadata that would allow tools to handle it right away
instead of reacting to the error response.
For a practical example look at datasources. Due to limitations in JCA
we have to restart the resource adapter if the jdbc connection url
changes. While it should be possible to one day make this change hot, we
can for the time being still allow the user to type in a value. They
would however be prompted with some kind of dialogue that would confirm
the impact of this change.
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 11 months
'choices' in model (Transaction subsystem)
by Kabir Khan
When working through problems in the JMX facade I came across this
<xs:complexType name="process-id">
<xs:annotation>
<xs:documentation>
<![CDATA[
The process identifer implementation
The "node-identifier" attribute is used to set the node identifier on the core environment.
The "socket-process-id-max-ports" attribute is used to set the max ports on the core environment.
]]>
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="uuid" type="uuid" />
<xs:element name="socket" type="socket-id" />
</xs:choice>
</xs:complexType>
<xs:complexType name="uuid">
<xs:annotation>
<xs:documentation>
<![CDATA[
The UUID based process identifer implementation
]]>
</xs:documentation>
</xs:annotation>
</xs:complexType>
<xs:complexType name="socket-id">
<xs:annotation>
<xs:documentation>
<![CDATA[
The socket based process identifer implementation
The "socket-binding" attribute is used to specify the port to bind to.
The "socket-process-id-max-ports" attribute is used to set the max ports on the core environment.
]]>
</xs:documentation>
</xs:annotation>
<xs:attribute name="socket-binding" type="xs:string" use="required"/>
<xs:attribute name="socket-process-id-max-ports" type="xs:int" default="10" />
</xs:complexType>
In the model this is represented as:
"core-environment" => {
"description" => "The core environment configuration.",
"type" => OBJECT,
"required" => true,
"value-type" => {
"node-identifier" => {
"description" => "Used to set the node identifier on the core environment.",
"type" => STRING,
"default" => 1,
"required" => false
},
"process-id" => {
"description" => "The Process id type; one of uuid, socket, file, mbean.",
"type" => OBJECT,
"min-length" => 1,
"required" => true
},
"uuid" => {
"description" => "The process-id/uuid element indicating to use the UUID based process id.",
"type" => STRING,
"min-length" => 0,
"required" => false
}
},
"access-type" => "read-only",
"storage" => "configuration"
},
The problem is the process-id where type=OBJECT and there is no value_type. From the schema it looks like it can be either a socket or a uuid. From a quick look at the parser it looks like both uuid and process-id become children of process-id (so I think the uuid sibling of process-id is wrong).
However, when possible I think anything with a type=OBJECT should have a value-type, otherwise the JMX facade has no idea what to do, and needs to fall back to a formatted JSON string.
I think a better version of this and the corresponding add operation would be:
"value-type" => {
"node-identifier" => {
"description" => "Used to set the node identifier on the core environment.",
"type" => STRING,
"default" => 1,
"required" => false
},
"process-id" => {
"description" => "The Process id type; one of uuid, socket, file, mbean.",
"type" => OBJECT,
"min-length" => 1,
"required" => true
"value-type" => {
"uuid" => {
"description" => "The process-id/uuid element indicating to use the UUID based process id.",
"type" => STRING,
"min-length" => 0,
"required" => false
},
"socket" => {
"type" => "OBJECT",
"value-type" => {
"socket-binding" => STRING,
"socket-process-id-max-ports" => INT
}
}
}
}
}
That way we can specify these properly in the mbean descriptions. Entering JSON stuff by hand is a pain….
14 years, 11 months
