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] > >
