[
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.
