qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea Gazzarini (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1284) QMan : Qpid JMX Management Bridge
Date Fri, 26 Sep 2008 11:23:44 GMT

     [ https://issues.apache.org/jira/browse/QPID-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrea Gazzarini updated QPID-1284:
-----------------------------------

    Attachment: commons-pool-1.4.jar
                qman_patch

Hi all! 
here's the second version of QMan. I attached to this post two files: 

- qman_patch : the patch (svn -diff) containing all qman files.
- commons-pool-1.4.jar : a dependency used for qman connection pool.


*** FEATURES INCLUDED ***

- Content indication response message ('i') handler;
- Content indication response message ('c') handler;
- Schema response ('s') handler;
- Optional properties management;
- Properties validation against using constraints defined in the schema (max, min, maxlen);
- Schema-hash / class-hash management. QMan is able to work with classes having different
schema inside the same package.
- Method invocation (see open issue below for this point) with arguments validation using
constraints define in the schema;
- Graceful shutdown (At shutdown all management clients are shutdown and corresponding resources
are released)
- Connection Pool : for each connected broker you can define (using configuration) a dedicated
connecton pool. Properties of connection pool are : max capacity, initial capacity, max wait
timeout. If you want for example to open all connections at startup set the initial capacity
= max capacity. 
- Each class is responsible to request and build its own schema. So, for example, if a runtime,
the remote broker adds a new class and sends instrumentation or configuration data, a corresponding
(empty) class definition will be created on QMan; immediately after that, the just created
class will request its schema.

*** OPEN POINTS ***

1) Logging should be better : I mean, all messages should be prefixed with an id like <QMAN-xxxxxx>.
At the moment not all messages are in this format.
2) Code used for sending messages should be better (see QpidClass.schemaRequest() and QpidClass.methodRequest());
3) Overloaded methods : At the moment each method is defined using its name as identifier
and that thing doesn't work for overloaded methods...
4) Default handlers (opcode handlers) must be hard-coded. Only add-on handler must be configurable.
At the moment you can add & remove handler using configuration but in this way it's possible
to remove the default handlers from the configuration and therefore QMan won't work at all!
5) Method invocation : there is an echo() method on broker object instance that is throwing
an exception while getting the response. It's strange because other method invocations are
working (solicitAck(), close(), purge()). I'm working on that...
5) Return values : are not handled at the moment : command messages must be sent synchronously
in order to get the response message and pack the return value(s) in a composite structure
used a return object; At the moment the corresponding handler for 'm' message is simply log
(debug level) the content of the message, including status text and status code.
6) It's not clear how to represent events on QMan (Is it useful?)
7) Offline testcase must be made for all QMan features. There's still a lot of code duplication
too  :(
8) Online testcase are missing.
9) Performance test cases (using something like JPerf) are missing.
10) ManagementDecoder & ManagementEncoder : I don't like very much those classes. For
my opinionthe additional behaviour should be added on the 
corresponding BBDecoder & BBEncoder.

*** Configuration file (org.apache.qpid.management.config.xml) ****

1) RESPONSE MESSAGE HANDLERS

An handler is responsible to handle a message response with a specific opcode. You can configure
handlers under the /configuration/message-handlers. 
First, you can configure an handler for response messages coming from management queue and
/ or method-reply queue. 
The first category can be defined under the /configuration/message-handlers/method-reply-queue
while the second one under /configuration/message-handlers/management-queue. 
An handler is configured defining two parameters 

<opcode>x</opcode> --> the opcode
<class-name>xxx.xxx.xx.xxx</class-name> --> the implementation class 

2) TYPE MAPPINGS
A type mapping declares a mapping between a code (defined in management specification) and
a concrete implementor of org.apache.qpid.management.domain.model.type.Type. 
At the moment concrete implementors are:

org.apache.qpid.management.domain.model.type.AbsTime.java
org.apache.qpid.management.domain.model.type.Binary.java
org.apache.qpid.management.domain.model.type.Boolean.java
org.apache.qpid.management.domain.model.type.DeltaTime.java
org.apache.qpid.management.domain.model.type.Map.java
org.apache.qpid.management.domain.model.type.ObjectReference.java
org.apache.qpid.management.domain.model.type.Str16.java
org.apache.qpid.management.domain.model.type.Str8.java
org.apache.qpid.management.domain.model.type.Type.java
org.apache.qpid.management.domain.model.type.Uint16.java
org.apache.qpid.management.domain.model.type.Uint32.java
org.apache.qpid.management.domain.model.type.Uint64.java
org.apache.qpid.management.domain.model.type.Uint8.java
org.apache.qpid.management.domain.model.type.Uuid.java

Anyway a type is defined under the /configuration/type-mappings/mapping using specifying properties:

<mapping>
	<code>x</code> --> as defined in the management specification
	<class-name>xx.xxx.xxx.xx.x</class-name> --> a concrete implementor of org.apache.qpid.management.domain.model.type.Type
(see above)
</mapping>

3) ACCESS MODE MAPPINGS
A mapping between a code and a Access mode as defined on management specification.
It is configured under /configuration/access-mode-mappings/mapping using these properties
:

<mapping>
	<code>x</code> --> as defined in the management specification
	<value>x</class-name> --> RC,RW,RO
<mapping>

4) BROKERS
QMan is able to connect with one or more brokers. In order to do that each broker is configured
under a dedicated /configuraton/brokers/broker using the following properties :

<broker>            
	<host>192.168.148.131</host>   --> host name
	<port>5672</port> --> port 
	<virtual-host>test</virtual-host> --> virtual host
	<user>pippo</user> --> username
	<password>pluto</password> --> password
	<max-pool-capacity>4</max-pool-capacity> --> connection pool max capacity
	<initial-pool-capacity>4</initial-pool-capacity> --> connetion pool initial
capacity
	<max-wait-timeout>-1</max-wait-timeout> --> wait time timeout (-1 stands for
forever)
<broker>

*** DEPENDENCIES ***
qpid-common-incubating-M3.jar (already part of qpid) 
qpid-client-incubating-M3.jar (already part of qpid)
slf4j-api-1.4.0.jar (already part of qpid)
slf4j-log4j12-1.4.0.jar (already part of qpid)
mina-filter-ssl-1.0.1.jar (already part of qpid)
mina-core-1.0.1.jar (already part of qpid)
log4j-1.2.12.jar (already part of qpid)
commons-pool-1.4.jar (not part of qpid but attached to this post)


*** PREREQUISITES ****

You should have in your classpath a log4j.xml configuration file with a category defined as
this : 

<category name="org.apache.qpid.management">
	<priority value="INFO"/>
</category>

it should be better if output is redirected to a file using a FileAppender.  

Now after set the classpath with the mentioned dependencies run :

> java -Dcom.sun.management.jmxremote org.apache.qpid.management.domain.services.QMan 

If you open the jconsole ($JAVA_HOME/bin/jconsole) you will be able to see (under a Q-MAN
domain) all the objects of the connected broker(s) as MBeans.      

Regards,
Andrea

> QMan : Qpid JMX Management Bridge
> ---------------------------------
>
>                 Key: QPID-1284
>                 URL: https://issues.apache.org/jira/browse/QPID-1284
>             Project: Qpid
>          Issue Type: New Feature
>    Affects Versions: M3
>         Environment: J2SE 5, any OS that is supporting Java
>            Reporter: Andrea Gazzarini
>         Attachments: commons-pool-1.4.jar, DomainModel.jpg, QMan.jar, qman_patch, QpidClass.jpg
>
>
> QMan is an application used for exposing via JMX the management domain model of one or
more remote brokers.
> Capabilities (the list is not complete) : 
> - Operates from a formally defined management schema;
> - Uses the AMQP protocol and its type system for communicating with remote brokers;
> - Exposes via JMX the remote broker domain model: that means for each connected broker
QMan lets you see its domain model entities according to their schema (attribute, methods,
statistics and events). In addition, lets you invoke operations on those entities.  
> - Multi broker management; 
> - It doesn't have prior knowledge of the management model of the system under management.
no definition is hard-coded and entity definitions (schema) are requested and built "on demand";
> - Namespace separation between brokers : each connected broker can have a different schema.

> - JMX interface : QMan is itself a Management Bean and using JMX it exposes its public
interface (for example, to connect with a new broker). So at the end it should be exposed
via WS-DM, SMTP, RMI, etc...
>       

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message