jmx-dev JEP review : JDK-8171311 - REST APIs for JMX
Harsha Wardhana B
harsha.wardhana.b at oracle.com
Tue Sep 12 14:16:15 UTC 2017
Hi Kirk,Erik,
The current JEP addresses the first use-case. Second use case can be
realized by adding a JMXConnector that operates over REST APIs provided
by the current JEP. But that is outside the scope of this JEP.
-Harsha
On Tuesday 12 September 2017 04:27 PM, Kirk Pepperdine wrote:
>
>> On Sep 12, 2017, at 12:44 PM, Erik Gahlin <erik.gahlin at oracle.com
>> <mailto:erik.gahlin at oracle.com>> wrote:
>>
>> I guess there are two use cases:
>>
>> 1) Simple interoperability with other languages.
>> 2) A drop in replacement for RMI
>>
>> Can a JMX connector be written that support both use cases? I don't
>> know, but if not it could be that we need both a connector and an
>> adapter.
>
> I think if you were to extend JMXConnector to wrap the REST API you
> might be able to expose both. But I’m not sure it would be a great
> solution. I think a second JEP would be a better option.
>
> — Kirk
>
>>
>> Erik
>>
>>> Hi Kirk,
>>>
>>> I guess the term 'connector' here is loosely applied. When I say
>>> connector, I mean the connector that provides implementation of the
>>> package below,
>>>
>>> https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html
>>>
>>> RMIConnector is one implementation of above connector.
>>>
>>>
>>> On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote:
>>>> Hi Harsha,
>>>>
>>>> From Chapter 5 of the JMX documentation. "Many different
>>>> implementations of connectors are possible. In particular, there
>>>> are many possibilities for the protocol used to communicate over a
>>>> connection between client and server.”
>>>>
>>>> It goes on in the Generic Connector section under "User-Defined
>>>> Protocols” to say; "While the RMI connector must be present in
>>>> every implementation of the JMX Remote API, you can also implement
>>>> a connector based on a protocol that is not defined in the JMX
>>>> Remote API standard. A typical example of this is a connector based
>>>> on a protocol that uses HTTP/S. Other protocols are also possible.
>>>> The JMX specification describes how to implement a connector based
>>>> on a user-defined protocol.”
>>>>
>>>> Unless I’m missing something, this all suggests that there is
>>>> nothing inherently wrong is using REST behind a JMXConnector.
>>> I hope above should clarify what I refer to when I say JMXConnector.
>>> In that sense, REST APIs alone cannot work as connector. In fact, it
>>> stands parallel to connector, as in it directly wraps the
>>> MBeanServer and does not wrap any JMXConnector. The JEP has detailed
>>> information about where the REST adapter sits in the JMX architecture.
>>>
>>> Are you suggesting that we implement a JMXConnector that works over
>>> REST?
>>>>
>>>> As written this JEP pretty much looks like Jolokia. Jolokia is a
>>>> great project and as such I fail to see the benefits of simply
>>>> duplicating it. I’d also argue that the usefulness of that project
>>>> has been some what muted because it is not a drop in replacement
>>>> for the standard RMI connector meaning that one has to modify an
>>>> entire tool chain just to make use of it. However, creating a REST
>>>> based JMXConnector would be immediately useful.
>>>> As an aside, Jus last week I started on a JMXConnector that uses a
>>>> shared memory segment for communications. Of course this
>>>> implementation would only be available for local communications but
>>>> it offers some advantages over using a socket based protocol, even
>>>> if that comms is over local loopback.
>>>>
>>>> Kind regards,
>>>> Kirk Pepperdine
>>>
>>> Thanks
>>> Harsha
>>>>
>>>>
>>>>
>>>>> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B
>>>>> <harsha.wardhana.b at oracle.com> wrote:
>>>>>
>>>>> Hi Kirk,
>>>>>
>>>>> REST APIs work as an adapter and cannot work as a connector. To
>>>>> quote from the JEP,
>>>>>
>>>>>
>>>>>> The REST adapter is a part of the Distributed services level.
>>>>>> Connectors mirror the interfaces of agent level services to
>>>>>> remote clients, whereas adapters transform agent level services
>>>>>> to different protocol. The proposed functionality will transform
>>>>>> Agent level services to REST APIs, hence the name "REST adapter".
>>>>> A connector *must* adhere to the JMX remoting spec. REST APIs
>>>>> cannot adhere to that because they expose APIs via HTTP and not
>>>>> Java. Hence it is called an Adapter and not a connector. It can
>>>>> never work as a 'drop-in' replacement for JMX/RMI Connector.
>>>>> Existing tools using using RMIConnector will have to be modified
>>>>> to use REST APIs.
>>>>>
>>>>> The current JEP does not allow all of the CRUD operations on
>>>>> MBeans. In the spirit of keeping the APIs language agnostic, only
>>>>> read/write is supported. It is not possible to specify
>>>>> create/delete REST APIs for JMX without incorporating language
>>>>> specific features. I would welcome discussions around including
>>>>> create/delete APIs for MBeans.
>>>>>
>>>>> In lieu of the above, as of now REST adapter cannot exist
>>>>> independently and will have to live along-side RMIConnector.
>>>>>
>>>>> -Harsha
>>>>>
>>>>>
>>>>> On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote:
>>>>>> Hi Harsha,
>>>>>>
>>>>>> The only reason I mentioned Jolokia is that it’s a project that
>>>>>> usefulness is some what limited because it is *not* a compliment
>>>>>> JMX connector and as such cannot be used as a straight drop-in
>>>>>> replacement for the current RMI based connector. Is your plan
>>>>>> here to make it a fully compliant connector so that we could
>>>>>> configure tooling such as the MBean viewers in jConsole and
>>>>>> VisualVM (or JMC for that matter) to use a restful connector
>>>>>> instead of an RMI based connector? IMHO, doing so would represent
>>>>>> a huge win as I know of quite a few projects that cannot or will
>>>>>> not use JMX because of it’s reliance on RMI.
>>>>>>
>>>>>> Consolidating all of the options under a single flag looks like
>>>>>> another interesting win.
>>>>>>
>>>>>> Kind regards,
>>>>>> Kirk
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B
>>>>>>> <harsha.wardhana.b at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>>
>>>>>>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote:
>>>>>>>> Hi Harsha,
>>>>>>>>
>>>>>>>> I haven't looked at Jolokia, or know what is the most
>>>>>>>> reasonable approach in this case, but as a principle, I think
>>>>>>>> we should strive for the best possible design rather than
>>>>>>>> trying to be compatible with third party tools.
>>>>>>> Agreed. That will always be the first priority. That is the
>>>>>>> reason HTTP GET interfaces will not be changed. I am undecided
>>>>>>> if the POST payloads need to be changed (without compromising
>>>>>>> the REST design principles) to increase adoption of this feature.
>>>>>>>>
>>>>>>>> How will the command line look like to start the agent with the
>>>>>>>> rest adapter?
>>>>>>>>
>>>>>>>> In the past there have been discussions about adding syntactic
>>>>>>>> sugar for -Dcom.sun.management, i.e.
>>>>>>>>
>>>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false
>>>>>>>>
>>>>>>>> instead of
>>>>>>>>
>>>>>>>> -Dcom.sun.management.jmxremote.ssl=false
>>>>>>>> -Dcom.sun.management.jmxremote.port=7091
>>>>>>>> -Dcom.sun.management.jmxremote.authenticate=false
>>>>>>>>
>>>>>>>> which is hard to remember, cumbersome to write and error prone
>>>>>>>> since the parameters are not validated. If we are adding
>>>>>>>> support for REST, it could perhaps be default, i.e.
>>>>>>>>
>>>>>>>> -Xmanagement:ssl=false,authenticate=false,port=80
>>>>>>>>
>>>>>>>> If you want to use JMX over RMI you would specify protocol:
>>>>>>>>
>>>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi
>>>>>>> Yes. There is an enhancement request to add the -Xmanagemet:*
>>>>>>> syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST
>>>>>>> adapter will use one of the above flags though I haven't thought
>>>>>>> of the exact name for it yet. I will update the JEP with the
>>>>>>> details of the flag shortly.
>>>>>>>>
>>>>>>>> Has there been any thoughts about JMX notifications?
>>>>>>> Notifications will not be supported in this JEP.
>>>>>>>
>>>>>>> * MBean Notifications are not a widely used feature and will
>>>>>>> not be supported via the REST adapter.
>>>>>>>
>>>>>>>>
>>>>>>>> I know it is outside the scope of the JEP, but I think we
>>>>>>>> should take it into consideration when doing the design, so the
>>>>>>>> functionality could be added on later without too much difficulty.
>>>>>>> Notifications can be added without modifying the current design
>>>>>>> too much. If required, it will be worked upon via an enhancement
>>>>>>> request.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Erik
>>>>>>>>
>>>>>>> Thanks
>>>>>>> Harsha
>>>>>>>>>
>>>>>>>>> Hi Martin,
>>>>>>>>>
>>>>>>>>> In my opinion, the interfaces exposed by current JEP are lot
>>>>>>>>> closer to REST style than the interfaces exposed by Jolokia.
>>>>>>>>>
>>>>>>>>> For instance, HTTP GET by default should be used to read
>>>>>>>>> resources, but it is made part of URL in Jolokia interfaces.
>>>>>>>>>
>>>>>>>>> <base-url>/read/<mbean name>/<attribute name>/<inner path>
>>>>>>>>>
>>>>>>>>> I would wait on opinions from more people before considering
>>>>>>>>> changing the current interfaces.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Harsha
>>>>>>>>>
>>>>>>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote:
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> Would one at least consider adopting the same URL paths and
>>>>>>>>>> payloads as Jolokia? This could make life a lot easier for
>>>>>>>>>> third party tools that connect to it.
>>>>>>>>>>
>>>>>>>>>> Best Regards
>>>>>>>>>>
>>>>>>>>>> Martin Skarsaune
>>>>>>>>>>
>>>>>>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B
>>>>>>>>>> <harsha.wardhana.b at oracle.com>:
>>>>>>>>>>
>>>>>>>>>> Hi Kirk,
>>>>>>>>>>
>>>>>>>>>> Yes. Jolokia was considered and is listed as an
>>>>>>>>>> alternative in the JEP.
>>>>>>>>>>
>>>>>>>>>> * Jolokia can serve as a viable alternative but can be
>>>>>>>>>> bulky. We are looking for simple and lightweight
>>>>>>>>>> solution.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -Harsha
>>>>>>>>>>
>>>>>>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Have you run into this project?https://jolokia.org <https://jolokia.org/>. Unfortunately it’s not exactly a drop in replacement for the standard RMI based JMX connector but it’s not far off.
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Kirk
>>>>>>>>>>>
>>>>>>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin<erik.gahlin at oracle.com> <mailto:erik.gahlin at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Harsha,
>>>>>>>>>>>>
>>>>>>>>>>>> Looping in jmx-dev.
>>>>>>>>>>>>
>>>>>>>>>>>>> byte[], short[], int[], float[], double[]
>>>>>>>>>>>> Should long[] be included there as well?
>>>>>>>>>>>>
>>>>>>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser.
>>>>>>>>>>>> Is this an internal parser or will it be exposed as an API?
>>>>>>>>>>>>
>>>>>>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API?
>>>>>>>>>>>> http://openjdk.java.net/jeps/198
>>>>>>>>>>>>
>>>>>>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Erik
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review the JEP for REST APIs for JMX :
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311
>>>>>>>>>>>>>
>>>>>>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> -Harsha
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170912/073497c6/attachment-0001.html>
More information about the serviceability-dev
mailing list