jmx-dev JEP review : JDK-8171311 - REST APIs for JMX
Erik Gahlin
erik.gahlin at oracle.com
Tue Sep 12 10:44:12 UTC 2017
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.
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 <mailto: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
>>>>> <mailto: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
>>>>>>>> <mailto: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/e8becd25/attachment-0001.html>
More information about the serviceability-dev
mailing list