JMX interface stability and versioning

[Robbie Gemmell <ro...@gmail.com>]

Hi all. Just kicking off some discussion on issues likely to affect what
I do during the GSoC work, to help Aidan and I put together a better
plan of action.

One upcoming elephant to consider is going to be AMQP 1.0 support and
how its new messaging/component model will affect the management
interfaces. As the Java broker is presumably going to support the
current protocol versions and gain 1.0 (+ 0-10), this could/will
somewhat muddy the management waters.

Eg, Exchanges (sort of) going away, Links being added...VirtualHosts
becoming merely part of the implementation details etc. This would
presumably mean some methods being added, removed, or possibly moved to
new/existing MBeans. Alternatively, an entirely new set of JMX
interfaces could be exposed and coexist with the existing set to handle
the new model and old models seperately, moving to just the new set at
some future time. So many possible options...

Another issue for discussion is versioning. In the previous work I did
on the broker JMX capabilities, some issues cropped up with
compatibility due to a required a change in the expected input (going
from MD5-hashed password input to plain text to support a consistent
user management interface) for some of the methods. Additional changes
included altering of some attribute units for correctness and
consistency, and introduction of some new attributes for FTD (since
removed). These changes made it necessary and/or desirable to be able to
distinguish the versions of each JMX MBean encountered, so a version
property was added to the JMX ObjectName to do so. Depending on changes
made to account for 1.0 management, it may be necessary or useful to
rework this as well.

Any thoughts out there? :)

Robbie


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

Re: JMX interface stability and versioning

[Aidan Skinner <ai...@gmail.com>]

On Wed, Apr 29, 2009 at 9:47 PM, Robbie Gemmell
<ro...@gmail.com> wrote:

>> I think we should exclude Desired Future Endstate from consideration
>> for this work. The 0-10 stuff is obviously relevant, since it will be
>> taking place concurrently.
>
> Ok. I only really mentioned it due to past discussions where interest was
> expressed for doing 0-10 in concert with/on top of 1.0 work, so I figured
> any discussions there might get slightly intertwined.

Yeah. I think we'll just need to see how that plays out as this goes on.

>> We're going to need to keep the existing API for a bit, if we're going
>> to be breaking stuff I strongly feel we need to do it for everything
>> at once (server config, client APIs etc).
>
> +1
>
> Any discussions of major change were only in reference to any 1.0
> consideration, I don't think there is any other point on the horizon that
> justifies/requires break-inducing changes being considered.

I'm hoping that if we can also answer the question about how modules
can contribute management functionality that will mostly take care of
this problem.

> Indeed, although extending stuff in general doesn't need to be as messy as
> the above bit was. That was mainly the result of changing the required input
> or units of existing functionality because it was totally braindead :)

Seriously. The MaxQueueDepth thing was just hateful. I'm glad that's
behind us. :)

Is it worth talking about changes to the UI itself now and work out
any necessary new bits as we go, or, indeed, have you already
identified most of them?

- Aidan
-- 
Apache Qpid - Give me convenience or give me death
http://qpid.apache.org

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

RE: JMX interface stability and versioning

[Robbie Gemmell <ro...@gmail.com>]

> -----Original Message-----
> From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
> Sent: 29 April 2009 18:42
> 
> On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> 
> > One upcoming elephant to consider is going to be AMQP 1.0 support and
> > how its new messaging/component model will affect the management
> > interfaces. As the Java broker is presumably going to support the
> > current protocol versions and gain 1.0 (+ 0-10), this could/will
> > somewhat muddy the management waters.
> 
> I think we should exclude Desired Future Endstate from consideration
> for this work. The 0-10 stuff is obviously relevant, since it will be
> taking place concurrently.

Ok. I only really mentioned it due to past discussions where interest was
expressed for doing 0-10 in concert with/on top of 1.0 work, so I figured
any discussions there might get slightly intertwined. 


> Having said that, I think that there's definitely some work that can
> be done to improve the current API.
> 
> > presumably mean some methods being added, removed, or possibly moved
> to
> > new/existing MBeans. Alternatively, an entirely new set of JMX
> > interfaces could be exposed and coexist with the existing set to
> handle
> > the new model and old models seperately, moving to just the new set
> at
> > some future time. So many possible options...
> 
> We're going to need to keep the existing API for a bit, if we're going
> to be breaking stuff I strongly feel we need to do it for everything
> at once (server config, client APIs etc).

+1

Any discussions of major change were only in reference to any 1.0
consideration, I don't think there is any other point on the horizon that
justifies/requires break-inducing changes being considered.

> 
> Creating a new one entirely might not be inappropriate, but we are
> going to have to coordinate it with qpid-cli amongst others. If we do
> decide to do this we're going to need to do some requirements
> gathering.
> 
> > Another issue for discussion is versioning. In the previous work I
> did
> > on the broker JMX capabilities, some issues cropped up with
> > compatibility due to a required a change in the expected input (going
> > from MD5-hashed password input to plain text to support a consistent
> > user management interface) for some of the methods. Additional
> changes
> > included altering of some attribute units for correctness and
> > consistency, and introduction of some new attributes for FTD (since
> > removed). These changes made it necessary and/or desirable to be able
> to
> > distinguish the versions of each JMX MBean encountered, so a version
> > property was added to the JMX ObjectName to do so. Depending on
> changes
> > made to account for 1.0 management, it may be necessary or useful to
> > rework this as well.
> 
> This makes doing that a bit easier. It's not something we want to do
> lightly but it might be helpful. :)
> 
> One question we really want to solve is how to add functionality in a
> less intrusive manner. Once we reach a stable API we're going to still
> need to be able to extend it, and have plugins contribute their own
> management functionality easily and portably.
> 
> - Aidan

Indeed, although extending stuff in general doesn't need to be as messy as
the above bit was. That was mainly the result of changing the required input
or units of existing functionality because it was totally braindead :)



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

Re: JMX interface stability and versioning

[Aidan Skinner <ai...@gmail.com>]

On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell
<ro...@gmail.com> wrote:

> One upcoming elephant to consider is going to be AMQP 1.0 support and
> how its new messaging/component model will affect the management
> interfaces. As the Java broker is presumably going to support the
> current protocol versions and gain 1.0 (+ 0-10), this could/will
> somewhat muddy the management waters.

I think we should exclude Desired Future Endstate from consideration
for this work. The 0-10 stuff is obviously relevant, since it will be
taking place concurrently.

Having said that, I think that there's definitely some work that can
be done to improve the current API.

> presumably mean some methods being added, removed, or possibly moved to
> new/existing MBeans. Alternatively, an entirely new set of JMX
> interfaces could be exposed and coexist with the existing set to handle
> the new model and old models seperately, moving to just the new set at
> some future time. So many possible options...

We're going to need to keep the existing API for a bit, if we're going
to be breaking stuff I strongly feel we need to do it for everything
at once (server config, client APIs etc).

Creating a new one entirely might not be inappropriate, but we are
going to have to coordinate it with qpid-cli amongst others. If we do
decide to do this we're going to need to do some requirements
gathering.

> Another issue for discussion is versioning. In the previous work I did
> on the broker JMX capabilities, some issues cropped up with
> compatibility due to a required a change in the expected input (going
> from MD5-hashed password input to plain text to support a consistent
> user management interface) for some of the methods. Additional changes
> included altering of some attribute units for correctness and
> consistency, and introduction of some new attributes for FTD (since
> removed). These changes made it necessary and/or desirable to be able to
> distinguish the versions of each JMX MBean encountered, so a version
> property was added to the JMX ObjectName to do so. Depending on changes
> made to account for 1.0 management, it may be necessary or useful to
> rework this as well.

This makes doing that a bit easier. It's not something we want to do
lightly but it might be helpful. :)

One question we really want to solve is how to add functionality in a
less intrusive manner. Once we reach a stable API we're going to still
need to be able to extend it, and have plugins contribute their own
management functionality easily and portably.

- Aidan
-- 
Apache Qpid - Give me convenience or give me death
http://qpid.apache.org

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