Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of kgiusti@redhat.com designates
 209.132.183.24 as permitted sender)
Date: Thu, 05 Jan 2012 09:42:57 -0500 (EST)
From: Ken Giusti <kgiusti@redhat.com>
To: dev@qpid.apache.org
Cc: users@qpid.apache.org
Subject: Re: QMF and Broker Management
Message-ID: 
 <1948103d-d911-4c9d-8ce5-da26e00a0734@zmail16.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4F0492AF.6080309@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

+1 - totally agree with this proposal.

----- Original Message -----
> Users and Devs,
> 
> I'd like to make a proposal and start a discussion about the future
> of
> QMF and Qpid broker management.
> 
> QMF (Qpid Management Framework) started out as a way to remotely
> manage
> the Qpid C++ broker using AMQP messaging.  There was an agent
> embedded
> in the broker and a console API written in Python.  It was then
> expanded
> for more general purpose use when an agent library and API were
> developed so developers could provide QMF manageability to their
> software components.
> 
> There has been quite a bit of evolution including new APIs and even a
> new protocol based on map/list-encoded messages.  One of the
> important
> changes that occurred with the new protocol (called qmf2) was that
> QMF
> became purely layered over AMQP messaging.  The original protocol
> required the participation of the broker to assign addresses, to
> track
> agents, and to cache schema information (didn't scale well, didn't
> work
> in multi-broker environments, had multiple protocol issues, wreaked
> havoc with clustering).
> 
> The QMF code is embedded in the "qpid" namespace because older
> versions
> were tightly coupled to the broker code.  Now that the coupling has
> been
> reduced (consisting of the public messaging API), it is possible to
> move
> QMF out of the "qpid" namespace and allow it to be a separate
> component,
> with its own build and release artifacts.
> 
> I would like to propose that we:
> 
>  1. move the C++ implementation of qmf2 out of the qpid tree and into
>     the "extras" subdirectory (where the Python implementation is),
>  2. move the swig bindings (Python, Ruby, etc.) into extras as well,
>  and
>  3. deprecate the old qmf components.
> 
> The old components are in:
> 
>   * cpp/{include,src}/console
>   * cpp/{include,src}/agent
>   * cpp/{include,src}/qmf/engine
>   * cpp/bindings/qmf
> 
> The last part of the proposal is to remove the dependency that the
> qpid
> tools (qpid-config, qpid-stat, qpid-route, etc.) have on the Python
> QMF
> library.  If you haven't noticed, these tools run fairly slowly,
> especially when grouped in large numbers in a script file.  This is
> because QMF (version 1) has a significant amount of handshake that
> occurs on connection setup.  Since the tools don't need
> agent-discovery
> or schema-introspection, they can operate much more simply by sending
> and receiving properly formatted messages to and from the broker
> agent.
> I prototyped this with qpid-stat and found it to be visually
> instantaneous in its response time.  It also reduced the number of
> queues and bindings related to the management session to one.
> 
> Fraser Adams has contributed a Java implementation of the new QMF
> protocol.  It makes sense to me that this should be included with the
> C++ and wrapped components that I propose moving into "extras".
> 
> Thoughts?
> 
> Regards,
> 
> -Ted
> 
> 

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org