Thank you very much Rob. That is very helpful. We are using the following operations on Qpid broker through JMX: 1. Getting queue information (Message count, Queue depth, Active consumer count, etc) 2. Getting metadata of individual messages in a queue (JMS message ID, JMS timestamp, delivery count, size in bytes, etc.) 3. Getting the list of JMS connections to the broker (for monitoring) 4. Shutting down the broker 5. Deleting messages 6. Closing JMS connections from broker side
Thanks Ramayan On Tue, Aug 23, 2016 at 2:28 AM, Rob Godfrey <[email protected]> wrote: > To expand on Lorenz's response: > > JMX will continue to be supported in 6.0.x (although not enabled by > default) - I'd expect us to continue releasing bug fix releases on this > branch until at least the end of 2017 (so another 15 months). 6.1 and > beyond will no longer support JMX management. > > There are a couple of reasons for us ending support for the JMX management > APIs. Firstly, the JMX APIs were introduced very early in the Broker's > evolution and no longer mapped well to the actual management functionality > available. The JMX APIs had only limited provision for versioning to allow > for API evolution, and the way the APIs were implemented internally meant > that adding / modifying new functionality was burdensome. In consequence > the JMX APIs had not evolved in some time and many necessary operations > were not available through JMX. > > In addition to the support/maintenance burden of continuing support for a > "legacy" management API, there were fundamental security issues with JMX > itself (although I believe Oracle has subsequently issued a security update > for the JRE addressing these) whereby even when using username/password > authentication it was possible for an attacker to force the JRE to > deserialise arbitrary objects. As such we could no longer recommend using > JMX in a production environment. > > In general we are also trying to reduce the number of ports, etc. that the > broker requires in order for the broker to be more easily deployable into > cloud-like environments. Ultimately we would like to be in the position > where AMQP and HTTP are served from the same port - this would never have > been possible with JMX / RMI. > > Theoretically it would be possible to build a JMX<->REST API bridge as a > standalone application so that your existing usage of JMX could > interoperate with a broker which does not natively support the JMX API. We > considered building such a bridge, but have instead been focussed on > delivering new functionality. Similarly if you wished to recreate the JMX > plugin within the broker you could probably do so, however I would suggest > targeting a migration to the REST API for management operations. > > In addition to the REST API, we will also be supporting AMQP management > (though this is specified in terms of AMQP 1.0, we will also be making it > available in AMQP 0-10, and AMQP 0-9-1), the AMQP Management API is ver > similar in concept to the REST API and will work from the same underlying > model within the broker. > > Out of interest, which operations are you predominantly using JMX for? > > Hope this helps, > Rob > > On 23 August 2016 at 09:16, Lorenz Quack <[email protected]> wrote: > > > Hello Ramayan, > > > > by common convention deprecated features eventually get removed > > after a deprecation period. I don't know exactly when JMX was > > first deprecated but in 6.0.x we stepped up the deprecation level > > by removing the documentation and the JMX ports from the default > > configuration. However, the actual code was not removed until > > 6.1.x. So, if you must you can still use it in 6.0.4. > > > > I let someone else comment on the strategic decision for its > > removal. > > > > Kind regards, > > Lorenz > > > > > > > > On 23/08/16 05:03, Ramayan Tiwari wrote: > > > >> Found the JIRA for removing JMX > >> > >> https://issues.apache.org/jira/browse/QPID-6915 > >> > >> Although, I couldn't find the reason why JMX is being removed. Could you > >> point out the reasons why JMX is no longer supported? > >> Thanks > >> Ramayan > >> > >> On Mon, Aug 22, 2016 at 5:05 PM, Ramayan Tiwari < > [email protected] > >> > > >> wrote: > >> > >> Hi all, > >>> > >>> We (at Salesforce) are currently using Qpid java 0.32 broker and in the > >>> process of moving to 6.0.4. We rely heavily on JMX to perform various > >>> kind > >>> of broker monitoring and management. > >>> > >>> There is no mention of JMX Management in the documentation of broker > >>> 6.0.4 > >>> [1]. The documentation of 6.0.0 has the following: > >>> > >>> "*Important * > >>> For new development work, the reader is directed towards the strategic > >>> Web > >>> Management Console and the REST API. Use the Web/REST interfaces in > >>> preference to JMX whenever possible. The JMX interface will be > withdrawn > >>> in > >>> a future release." > >>> > >>> Our understanding was that JMX support will be deprecated and not > >>> withdrawn, and we would very much prefer that way. It will require a > huge > >>> amount of work for us to move completely out of JMX. If it is going > away, > >>> could you let us know the timeline on this? > >>> > >>> Thanks > >>> Ramayan > >>> > >>> [1]. https://qpid.apache.org/releases/qpid-java-6.0.4/java- > >>> broker/book/Java-Broker-Management-Channel.html > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
