Re: JMX interface stability and versioning
On Wed, Apr 29, 2009 at 9:47 PM, Robbie Gemmell 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-subscr...@qpid.apache.org
RE: JMX interface stability and versioning
> -Original Message- > From: Aidan Skinner [mailto:aidan.skin...@gmail.com] > Sent: 29 April 2009 18:42 > > On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell > 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-subscr...@qpid.apache.org
Re: JMX interface stability and versioning
On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell 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-subscr...@qpid.apache.org
JMX interface stability and versioning
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-subscr...@qpid.apache.org