JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

[mandy chung]

They are both supported API.  So one is not any easier than the other.

Mandy


On 8/3/17 8:08 PM, Hohensee, Paul wrote:
>
> Thought it would be an easier path, but I didn’t know for sure, hence 
> my question.
>
> Thanks,
>
> Paul
>
> *From: *Mandy Chung <mandy.chung at oracle.com>
> *Date: *Thursday, August 3, 2017 at 5:10 PM
> *To: *"Hohensee, Paul" <hohensee at amazon.com>
> *Cc: *Ujwal Vangapally <ujwal.vangapally at oracle.com>, 
> serviceability-dev <serviceability-dev at openjdk.java.net>
> *Subject: *Re: JDK-8185003 JMX: Add a version of 
> ThreadMXBean.dumpAllThreads with a maxDepth argument
>
> Why?  There is a reasonable request to 
> java.lang.management.ThreadMXBean.  dumpAllThreads and getThreadInfos 
> methods should have taken the maxDepth parameter when it was 
> introduced.  Unfortunately they didn’t and need to add two new methods 
> to it.
>
> Mandy
>
>     On Aug 3, 2017, at 1:42 PM, Hohensee, Paul <hohensee at amazon.com
>     <mailto:hohensee at amazon.com>> wrote:
>
>     Add it to com.sun.management.ThreadMXBean rather than
>     java.lang.management.ThreadMXBean?
>
>     Paul
>
>     *From: *serviceability-dev
>     <serviceability-dev-bounces at openjdk.java.net
>     <mailto:serviceability-dev-bounces at openjdk.java.net>> on behalf of
>     Mandy Chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>>
>     *Date: *Thursday, August 3, 2017 at 1:04 PM
>     *To: *Ujwal Vangapally <ujwal.vangapally at oracle.com
>     <mailto:ujwal.vangapally at oracle.com>>
>     *Cc: *serviceability-dev <serviceability-dev at openjdk.java.net
>     <mailto:serviceability-dev at openjdk.java.net>>
>     *Subject: *Re: RFR: JDK-8185003 JMX: Add a version of
>     ThreadMXBean.dumpAllThreads with a maxDepth argument
>
>         On Aug 3, 2017, at 8:24 AM, Ujwal Vangapally
>         <ujwal.vangapally at oracle.com
>         <mailto:ujwal.vangapally at oracle.com>> wrote:
>
>         Thanks for the review Erik,
>
>         I will investigate more considering Daniel's comment.
>
>         Adding a public method to an interface is an incompatible
>         source change unless there is a default body. On the other
>         hand I am not sure how MXBean proxies will work when proxying
>         an interface containing a default body. It would be
>         interesting to check this.
>
>     ThreadMXBean is a platform MXBean and so JDK implementation is the
>     one implementing it.  The real question here is that when
>     MBeanServerConnection.invoke is called on this new method that
>     does not exist in the remote MBeanServer (running on JDK 9 for
>     example), does it get javax.management.ReflectionException?  Or
>     something else?
>
>     Similarly, when the client gets a proxy of ThreadMXBean from a
>     remote MBeanServer running on JDK 9 VM, and it calls this method,
>     what exception does it get?  We may need to update the spec to
>     indicate this error cases if it’s not clear.  The notes in
>     ManagementFactory.newPlatformMXBeanProxy covers some cases due to
>     the difference in the client/server are running on.
>
>     Mandy
>
>         kindly use below webrev for referring changes as webrev.00 is
>         not accessible.
>
>         http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.01/
>         <http://cr.openjdk.java.net/%7Euvangapally/webrev/2017/8185003/webrev.01/>
>
>         -Ujwal
>
>         On 8/3/2017 8:00 PM, Erik Gahlin wrote:
>
>             Looks good, not a reviewer.
>
>             Nit, saw that spaces before commas were missing in some
>             method calls, i.e. ",-1" instead of ", -1"
>
>             Erik
>
>
>
>                 Hi,
>
>                 kindly review the changes made.
>
>                 https://bugs.openjdk.java.net/browse/JDK-8185003
>
>                 webrev:
>                 http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.00/
>                 <http://cr.openjdk.java.net/%7Euvangapally/webrev/2017/8185003/webrev.00/>
>
>
>                 CSR: https://bugs.openjdk.java.net/browse/JDK-8185705
>
>                 Thanks,
>
>                 Ujwal.
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170803/a0560ea8/attachment.html>