[jira] Commented: (QPID-1284) QMan : Qpid JMX Management Bridge

["Andrea Gazzarini (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637920#action_12637920 ] 

Andrea Gazzarini commented on QPID-1284:
----------------------------------------

Hi All, I have some doubts about remote management of Qpid Broker.

Running QMan I'm able to see several types of objects (queue, connection, session and so on). Those objects have methods that I can invoke. 
Now, there are some methods that in my opinion shouldn't be exposed for management. I mean shouldn't be part of the management interface.
What are those methods? In general  methods that control lifecycle of a specific object and specifically methods that are destroying / closing / invalidating an object.

Those operations should be controlled by the owning broker and in my opinion is not good to let an external client terminate those objects.

First possible  scenario :

1) QMan starts up. At least it needs one connection and one session
2) An external client connects to QMan using an XXX connector (where XXX could be RMI, WSDM, etc...) 
3) The external client invoke the close() operation on the connection instance that is used by QMan 
4) Result : QMan suicide
    
Second possible  scenario :

1) QMan starts up. At least it needs one connection and one session
2) An external client connects to QMan using an XXX connector (where XXX could be RMI, WSDM, etc...) 
3) The external client invoke the close() / detach() operation on the session instance that is used by QMan 
4) Result : QMan is no longer working...

Third possible scenario :

1) QMan starts up. At least it needs one connection and one session
2) An external client connects to QMan using an XXX connector (where XXX could be RMI, WSDM, etc...) 
3) The external client invoke the purge() operation on the management and / or queue instance that is used by QMan 
4) Result : QMan is not receiving management & method-reply messages

Fourth possible scenario :

1) QMan starts up and it connects to a broker already connected with other management clients. 
2) An external client connects to QMan using an XXX connector (where XXX could be RMI, WSDM, etc...) 
3) The external client invoke the close() operation on the connection instance that is used by another client 
4) Result : the other external client is no longer able to work.

...and so on...


What are you thinking about?

Let me know

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: actors.jpg, class_definition_building.jpg, commons-pool-1.4.jar, configuration_domain_model.jpg, DomainModel.jpg, estabilish_initial_connection.jpg, message_processing.jpg, QMan.jar, qman_patch, qman_patch_08102008, qman_predefined_handlers_patch, qman_test_cases_patch, qman_test_cases_patch_08102008, QpidClass.jpg, use_cases.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.