RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code

Hi All, Please review the fix for the bug, JDK-8170299 - Debugger does not stop inside the low memory notifications code webrev at, http://cr.openjdk.java.net/~hb/8170299/webrev.00/ Description of the fix: The debugger does not stop inside

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

utility in java to replace revokeall.exe.  As it has been a long-standing testing reliability issue and this is a test-only bug, you have time to fix in 11. Also, your fix does not work if "open" directory does not exist. Mandy On 6/27/18 9:28 AM, Harsha Wardhana B wrote: Since the

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

2018 09:52 PM, mandy chung wrote: I think the right thing to do is to bite the bullet and fix the test properly. In addition, this fix does not seem to work if there is no "open" directory. Mandy On 6/27/18 9:03 AM, Harsha Wardhana B wrote: That will be done subsequently and track

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

emove revokeall.exe sooner rather than later. Mandy On 6/26/18 7:09 AM, Harsha Wardhana B wrote: Hi All, Please find the fix for the bug, https://bugs.openjdk.java.net/browse/JDK-8192953 having webrev at, http://cr.openjdk.java.net/~hb/8192953/webrev.00/ The fix grants execute permission for revokeal

RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

Hi All, Please find the fix for the bug, https://bugs.openjdk.java.net/browse/JDK-8192953 having webrev at, http://cr.openjdk.java.net/~hb/8192953/webrev.00/ The fix grants execute permission for revokeall.exe. The paths in the shell sciprt had to be converted to cygwin paths (/cygwin/c/...

Re: RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

After internal discussions, we have decided to proceed with the current fix. Thank you Mandy, Daniel, Dan and David for the review. Harsha On Friday 22 June 2018 10:07 AM, Harsha Wardhana B wrote: Hi Dan, The utility function Utils.getFreePort gets free port by creating server socket with

Re: RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

y for how to fix it without breaking other tests (yet) so I just decommitted it from JDK11. I'm not saying that your current fix will be susceptible to very intermittent hangs on Solaris. I would have to take a very close look at it and I haven't done that yet. Dan On 6/21/18 2:47 AM, H

Re: RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

On Thursday 21 June 2018 10:30 AM, mandy chung wrote: On 6/20/18 1:14 AM, Harsha Wardhana B wrote: Hi, Please find the fix below for the bug JDK-8204661 : Show error 'Port already in use' in HashedPasswordFileTest.java having webrev at, http://cr.openjdk.java.net/~hb/8204

Re: RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

olmes wrote: Hi Harsha, On 20/06/2018 6:14 PM, Harsha Wardhana B wrote: Hi, Please find the fix below for the bug JDK-8204661 : Show error 'Port already in use' in HashedPasswordFileTest.java having webrev at, http://cr.openjdk.java.net/~hb/8204661/webrev.00/ The problem root-cau

RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

Hi, Please find the fix below for the bug JDK-8204661 : Show error 'Port already in use' in HashedPasswordFileTest.java having webrev at, http://cr.openjdk.java.net/~hb/8204661/webrev.00/ The problem root-cause is discussed in the comments section of the bug. The fix above lets the default

Re: Kerberos authentication for JMX?

Hi Peter, JMX agents support JAAS based authentication. The login module - Krb5LoginModule along with JAAS can be used to setup Kerberos-based authentication for JMX. A JAAS config file for Kerberos clients could look like, kerberosClient {    com.sun.security.auth.module.Krb5LoginModule

Re: Ping!! Re: RFR: 8203357 Container Metrics

[Replying to all mailing-lists] Hi Misha, The ERROR_MARGIN in tests was introduced to make the tests stable. There are times where metric values (specifically CPU usage) can change drastically in between two reads. The metrics value got from the API and the cgroup file can be different and 0.1

Re: Ping!! Re: RFR: 8203357 Container Metrics

Hi Misha, The ERROR_MARGIN in tests was introduced to make the tests stable. There are times where metric values (specifically CPU usage) can change drastically in between two reads. The metrics value got from the API and the cgroup file can be different and 0.1 ERROR_MARGIN should take care

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On Thursday 26 April 2018 09:09 PM, mandy chung wrote: On 4/23/18 1:20 PM, Harsha Wardhana B wrote: Hi All, After internal discussions, many of the concerns below were addressed and final spec is published at, https://bugs.openjdk.java.net/browse/JDK-8199584 Below is the implementation

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

asier to maintain.  We don't have a Java API for processing (VM) command line arguments so they are being shoehorned into properties. $.02, Roger On 2/21/2018 12:55 AM, Harsha Wardhana B wrote: On Wednesday 21 February 2018 01:51 AM, mandy chung wrote: The code review and CSR review

Re: RFR : JDK-8196744 : JMX: Not enough JDP packets received before timeout

Thanks David. -Harsha On Tuesday 20 March 2018 02:13 AM, David Holmes wrote: Hi Harsha, Given the negative nature of the test this approach seems quite reasonable. Thanks, David Harsha Wardhana B Ping! Can I have one more review for the below fix? Thanks Harsha On Monday 26 February

Re: RFR : JDK-8196744 : JMX: Not enough JDP packets received before timeout

Ping! Can I have one more review for the below fix? Thanks Harsha On Monday 26 February 2018 10:42 AM, Harsha Wardhana B wrote: Hello All, Requesting for review from one more reviewer. Thanks Harsha On Wednesday 21 February 2018 10:01 AM, Chris Plummer wrote: Hi Harsha, Not a review, but

Re: RFR : JDK-8196744 : JMX: Not enough JDP packets received before timeout

updated. thanks, Chris On 2/20/18 3:30 AM, Harsha Wardhana B wrote: Hi All, Please find the fix below for the Jdp test-case. issue: https://bugs.openjdk.java.net/browse/JDK-8196028 webrev : http://cr.openjdk.java.net/~hb/8196028/webrev.00/ Fix details : The test was receiving JDP packets from

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On Wednesday 21 February 2018 09:51 PM, mandy chung wrote: On 2/20/18 9:55 PM, Harsha Wardhana B wrote: We cannot get rid of specifying options via -D. We have plenty of -D flags but very few have short-hand alternative via --start-management-agent. If management properties are specified

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On Wednesday 21 February 2018 01:51 AM, mandy chung wrote: The code review and CSR review can be in parallel. For this case, I agree with Kumar to have CSR written that would help the code review. Please specify the behavior and its relationship with jcmd and other relevant diagnosability tool

Re: RFR : JDK-8196028 : JMX: Not enough JDP packets received before timeout

[Correcting bug Id in the subject] Thanks Erik. Harsha On Tuesday 20 February 2018 08:44 PM, Erik Gahlin wrote: Looks OK. Erik Hi All, Please find the fix below for the Jdp test-case. issue: https://bugs.openjdk.java.net/browse/JDK-8196028 webrev : http://cr.openjdk.java.net/~hb/8196028/w

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Ping. Could I please have reviews for below webrev. Thanks Harsha On Wednesday 14 February 2018 09:59 PM, Harsha Wardhana B wrote: Hi, Below is the updated webrev. http://cr.openjdk.java.net/~hb/8187498/webrev.03/ On Wednesday 14 February 2018 01:15 AM, mandy chung wrote: On 2/13/18 1

RFR : JDK-8196744 : JMX: Not enough JDP packets received before timeout

Hi All, Please find the fix below for the Jdp test-case. issue: https://bugs.openjdk.java.net/browse/JDK-8196028 webrev : http://cr.openjdk.java.net/~hb/8196028/webrev.00/ Fix details : The test was receiving JDP packets from other VM and hence the multi-cast socket was not timing-out. The def

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Hi, Below is the updated webrev. http://cr.openjdk.java.net/~hb/8187498/webrev.03/ On Wednesday 14 February 2018 01:15 AM, mandy chung wrote: On 2/13/18 1:30 AM, Harsha Wardhana B wrote: Hi, Please find below the revised webrev. http://cr.openjdk.java.net/~hb/8187498/webrev.02/ On

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Hi, Please find below the revised webrev. http://cr.openjdk.java.net/~hb/8187498/webrev.02/ On Friday 09 February 2018 05:07 AM, mandy chung wrote: On 2/7/18 1:19 AM, Harsha Wardhana B wrote: > > --start-management-agent will not be recognized in the current format and > hence

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

29 January 2018 03:14 PM, Harsha Wardhana B wrote: Hi Alan, I am not fully aware about Java launcher or how it passes options to VM. Let me check with some other folks and get back to you. Thanks Harsha On Monday 29 January 2018 01:55 PM, Alan Bateman wrote: On 29/01/2018 05:20, Harsha

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Below is the webrev with above changes and corresponding tests. http://cr.openjdk.java.net/~hb/8187498/webrev.01/ Please review and comment. Thanks Harsha On Monday 29 January 2018 03:14 PM, Harsha Wardhana B wrote: Hi Alan, I am not fully aware about Java launcher or how it passes options t

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Hi Alan, I am not fully aware about Java launcher or how it passes options to VM. Let me check with some other folks and get back to you. Thanks Harsha On Monday 29 January 2018 01:55 PM, Alan Bateman wrote: On 29/01/2018 05:20, Harsha Wardhana B wrote: Hi Mandy,Alan, Thanks for your

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

responding `-Dcom.sun.management.jmxremote.` rather than a VM option? Mandy [1] http://openjdk.java.net/jeps/293 On 1/24/18 11:21 PM, Harsha Wardhana B wrote: Hi Erik, The minimal command line would be, "-Xmanagement", that will start only the local management server. "-Xmanagement:l

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Hi Erik, The minimal command line would be, "-Xmanagement", that will start only the local management server. "-Xmanagement:local=true,port=" will start the remote management server without SSL or authentication. On Wednesday 24 January 2018 06:13 PM, Erik Gahlin wrote: Hi Harsha, Ver

RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ Thanks Harsha

Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received

JDK-8175542/webrev.01/> Thanks, Amit *From:*Harsha Wardhana B *Sent:* Wednesday, December 13, 2017 5:32 PM *To:* serviceability-dev@openjdk.java.net *Subject:* Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received Hi Amit, Increasing the timeout 'TIME_OUT_FACTOR' will increase

Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received

Hi Amit, Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and test-case timeout. The test passed as can be seen from the log, but because of the race-condition: hasTestLivedLongEnough() checked before shouldContinue(), the test was declared failed because of time-out. One p

Re: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java

Thanks Daniel and Christoph for review. -Harsha On Tuesday 05 December 2017 08:11 PM, Daniel Fuchs wrote: +1 -- daniel On 05/12/2017 12:04, Harsha Wardhana B wrote: Hi Daniel, On Tuesday 05 December 2017 03:42 PM, Daniel Fuchs wrote: Hi Harsha, Looks good. Thanks for the review. nit

Re: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java

lines are executed. An Assert statement at line 353 makes sure of that. Hence no point inverting the two if(). best regards, -- daniel Regards Harsha n 04/12/2017 18:27, Harsha Wardhana B wrote: Hi All, Please review and provide comments for fix for, issue: https://bugs.openjdk.java.net/

Re: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java

- From: serviceability-dev [mailto:serviceability-dev- boun...@openjdk.java.net] On Behalf Of Harsha Wardhana B Sent: Montag, 4. Dezember 2017 19:28 To: serviceability-dev@openjdk.java.net Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java Hi All

[TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java

Hi All, Please review and provide comments for fix for, issue: https://bugs.openjdk.java.net/browse/JDK-8192909 having webrev at, webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ Fix details: The test was failing intermittently because of duplicate entries for role in input passwor

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

changing logging level and internationalization as a separate issue. I have updated the webrev in-place. Please review and let me know if you are okay with it. Thanks Harsha On Friday 10 November 2017 07:50 PM, Daniel Fuchs wrote: Hi Harsha, On 10/11/2017 12:38, Harsha Wardhana B wrote: Hi

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

nks Harsha On Wednesday 08 November 2017 09:29 AM, mandy chung wrote: On 11/7/17 9:04 AM, Harsha Wardhana B wrote: Hi Mandy, To summarize the changes, 1. The header will not contain the file modification timestamp. Instead when the password file is modified, a debug log will be printed. Th

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

es validate the above use-case. best regards, -- daniel -Harsha On 07/11/2017 16:26, Harsha Wardhana B wrote: Hi, Please find below the webrev addressing Daniel and Mandy's comments. http://cr.openjdk.java.net/~hb/5016517/webrev.07/ -Harsha On Wednesday 01 November 2017 09:42 PM, Danie

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

. 3. HashedPasswordManager.authenticate accepts char[] for password instead of String. -Harsha On Tuesday 07 November 2017 10:24 PM, mandy chung wrote: On 11/7/17 8:26 AM, Harsha Wardhana B wrote: Hi, Please find below the webrev addressing Daniel and Mandy's comments.

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Hi, Please find below the webrev addressing Daniel and Mandy's comments. http://cr.openjdk.java.net/~hb/5016517/webrev.07/ -Harsha On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote: On 31/10/2017 17:07, mandy chung wrote: On 10/31/17 8:55 AM, Harsha Wardhana B wrote: Hi

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Hi Mandy, Below is the new webrev incorporating below review comments. http://cr.openjdk.java.net/~hb/5016517/webrev.06/ On Monday 30 October 2017 11:34 PM, mandy chung wrote: http://cr.openjdk.java.net/~hb/5016517/webrev.05/ Looks okay in general.   Daniel is closer to the FileLoginModule

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Sorry. Missed the webrev - http://cr.openjdk.java.net/~hb/5016517/webrev.05/ On Friday 27 October 2017 09:27 AM, Harsha Wardhana B wrote: Hi, Below is the updated webrev incorporating review comments from Daniel, Roger and Mandy. The password file will now be locked before writing. Mandy

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

ntation is required because the exact strings as specified in the documentation must be specified. "Java Security Standard Algorithm Names Specification" does not actually help. So I have not removed the link to the documentation. -Harsha On Thursday 12 October 2017 09:22 PM, Harsha Wardhan

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Sure. I will send out a modified webrev soon. -Harsha On Thursday 12 October 2017 08:52 PM, mandy chung wrote: On 10/12/17 8:18 AM, Harsha Wardhana B wrote: On Thursday 12 October 2017 08:40 PM, mandy chung wrote: On 10/12/17 1:16 AM, Harsha Wardhana B wrote: I'm thinkin

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

On Thursday 12 October 2017 08:40 PM, mandy chung wrote: On 10/12/17 1:16 AM, Harsha Wardhana B wrote: I'm thinking any better alternative to the new property name?? com.sun.management.jmxremote.password.hashes com.sun.management.jmxremote.password.asH

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Hi Mandy, On Wednesday 11 October 2017 11:48 PM, mandy chung wrote: On 10/8/17 10:34 PM, Harsha Wardhana B wrote: Hi Daniel, Below is the webrev addressing the review comments. http://cr.openjdk.java.net/~hb/5016517/webrev.04/ This approach seems reasonable.   I only review

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

needs hashing? Are there any protection in place to prevent the two processes from writing to the same file concurrently? best regards, -- daniel On 09/10/2017 06:34, Harsha Wardhana B wrote: Hi Daniel, Below is the webrev addressing the review comments. http://cr.openjdk.java.net/~hb/501

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

regards, -- daniel On 09/10/2017 06:34, Harsha Wardhana B wrote: Hi Daniel, Below is the webrev addressing the review comments. http://cr.openjdk.java.net/~hb/5016517/webrev.04/ On Friday 06 October 2017 03:38 PM, Daniel Fuchs wrote: Hi Harsha, Good work! > http://cr.openjdk.java.net/

Re: RFR : JDK-8044122 MBean access to the PID

Hi Ujwal, Could you please add a test-case to validate your changes? You can spawn a new process and it can exchange its pid to its parent via System.out/in or via sockets. Also, VMManagementImpl:145, the change from getProcessId to getVmPid seems unnecessary. -Harsha On Tuesday 10 Octob

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

it should send to the agent). Otherwise I think it looks good to me - provided all tests are passing! Done. Had a few test failures but nothing related to this enhancement. best regards, -- daniel Thanks Harsha On 06/10/2017 06:25, Harsha Wardhana B wrote: Hi All, Previously, for default

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

file. The fix for above and some off-list comments are incorporated in webrev below. http://cr.openjdk.java.net/~hb/5016517/webrev.03/ -Harsha On Wednesday 04 October 2017 01:53 PM, Harsha Wardhana B wrote: Hi Roger, Below is the webrev incorporating changes suggested by you. http

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

re used 'as is' all over the code to maintain isolation between pluggable login authenticator and JDK code. Roger Harsha On 10/3/2017 3:47 PM, Harsha Wardhana B wrote: Hi Roger, Thanks for the detailed review. Below is the webrev addressing all the review comments. http://

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

ed. Appropriate exceptions are thrown if file cannot be accessed. Is the re-writing of the passwords intended to be done by a 'priveleged' system. Does this need doPrivileged? I am not sure. Maybe it will be covered in the security review. * HashedPasswordFileTest: 8

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

opback. Kind regards, Kirk Pepperdine Thanks Harsha On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B 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 th

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

that comms is over local loopback. Kind regards, Kirk Pepperdine Thanks Harsha On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B mailto:harsha.wardhan...@oracle.com>> wrote: Hi Kirk, REST APIs work as an adapter and cannot work as a connector. To quote from the JEP, The REST adapt

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

ased 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 P

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

okia? 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 mailto:harsha.wardhan...@oracle.com>>: Hi Kirk, Yes. Jolokia was considered and is listed as an alternativ

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

<http://hawt.io> at JavaZone in a weeks time, and the recording is usually made available just a few hours later: https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590 Best regards Martin ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B mailto:harsha.wardhan...@oracle.com

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

that connect to it. Best Regards Martin Skarsaune ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B mailto:harsha.wardhan...@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

Re: JEP review : JDK-8171311 - REST APIs for JMX

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 int

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

Hi Erik, On Tuesday 05 September 2017 10:00 PM, Erik Gahlin wrote: Hi Harsha, Looping in jmx-dev. > byte[], short[], int[], float[], double[] Should long[] be included there as well? Yes. Thanks. > The REST adapter will come with a simple and lightweight JSON parser. Is this an internal

JEP review : JDK-8171311 - REST APIs for JMX

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 MBean

Re: RFR : JDK-8186224 javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException

Hi Ujwal, The changes look good. Thanks Harsha On Tuesday 22 August 2017 02:11 PM, Ujwal Vangapally wrote: Kindly review the changes made. Before these changes tests fail on windows if we execute them from any Drive other than C. grant codebase "file:/-" {} is granting permissions only

Re: RFR : 8182485 - JMX connections should have configurable ObjectInputFilter

Thanks for the review Daniel,Roger. -Harsha On Tuesday 20 June 2017 11:30 PM, Roger Riggs wrote: +1 Roger On 6/20/2017 1:24 PM, Daniel Fuchs wrote: The fix looks good to me Harsha. best regards, -- daniel On 20/06/2017 07:10, Harsha Wardhana B wrote: Hi, Please review the below RFE

Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address

jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server

Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address

Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperabili

RFR : 8182485 - JMX connections should have configurable ObjectInputFilter

Hi, Please review the below RFE, JDK-8182485 : JMX connections should have configurable ObjectInputFilter having webrev at http://cr.openjdk.java.net/~hb/8182485/webrev.00/ The enhancement adds ObjectInputFilter to JMX connections to configure filters during deserialization. -Harsha

Re: RFR: JDK-8178508 Co-locate remaining MM tests

Hi Ujwal, Looks fine. -Harsha On Thursday 01 June 2017 04:55 PM, Ujwal Vangapally wrote: Gentle reminder. Thanks, Ujwal. On 5/31/2017 10:32 AM, Ujwal Vangapally wrote: Kindly review the changes made for below bug converted tonga test to JTREG test added an additional assert statement

Re: RFR: JDK-6515161 If remote removeNotificationListener gets SecurityException, client no longer gets notifications

Hi Daniel, The term 'listenerid' is used in conjunction with method name/object field which adds context about the term 'listenerid'. Having a standalone method name as getClientListenerId is less ambiguous compared to method name : getListenerId. I don't really have a strong opinion on this

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Hello, Could I get one more reviewer for this enhancement? -Harsha On Thursday 27 April 2017 12:06 PM, Harsha Wardhana B wrote: Hi Roger, Thanks for the detailed review. I will wait for more review comments before incorporating the ones below. -Harsha On Tuesday 25 April 2017 10:56 PM

Re: RFR: JDK-6515161 If remote removeNotificationListener gets SecurityException, client no longer gets notifications

Hi Ujwal, The fix looks fine. Some nits. In ClientNotifForwarder.java, "getListenerIds" could be renamed to getClientListenrIds. -Harsha On Thursday 04 May 2017 12:29 PM, Ujwal Vangapally wrote: corrected webrev link : http://cr.openjdk.java.net/~uvangapally/webrev/2017/6515161/webrev.0

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

d unintentional subclassing. 113: canWriteToFile: It should be made clear in the template that *both* the Security policy and the file access value are used to check that the file can be updated. 200: loadPasswords() - should this confirm the access to the file is allowed and it has the corr

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Bernd -- http://bernd.eckenfels.net *From:* serviceability-dev on behalf of Harsha Wardhana B *Sent:* Sunday, April 23, 2017 12:20:57 PM *To:* serviceability-dev@openjdk.java.net *Subject:* RFE Review : JDK-5016517 - Replace

RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

Hi All, Please review this enhancement to replace plain-text password for JMX agent with SHA-256 hash. Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ Overview of implementati

Re: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters

testGetAttribute should verify that class of the returned value corresponds to what was declared in the MBeanAttributeInfo for the corresponding attribute. Sure. Will do. cheers, -- daniel -Harsha On 26/02/17 16:50, Harsha Wardhana B wrote: Hi All, Please review the below RFE, JDK-800714

Re: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters

-jtreg/work/java/lang/management/PerfCounterMBeanTest.d/testng.0.jta java/lang/management/PerfCounterMBeanTest.java PerfCounterMBeanTest sun.rt.jvmCapabilities --> 1100 sun.rt.jvmVersion --> 167772160 sun.rt.safepointSyncTim

Re: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters

Perfcounter are dynamic and can change. Applications must be aware of that and work around it. Perf counters being dynamic must be documented and must not be a deterrent for consuming them (via Dymanic MBean). Regards Harsha On Monday 27 February 2017 11:22 PM, Erik Gahlin wrote: If somebo

Re: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters

Hi Erik, I am not sure if Perf Counters could be disabled. If yes, then PerfCounter MBean must throw appropriate exception while getting MBeanInfo. I don't know about tests for PerfCounter. The webrev contains tests for PerfCounter MBean. I am not sure how we will be breaking other's code.

RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters

Hi All, Please review the below RFE, JDK-8007141 : Introduce Dynamic MBean exposing the perf counters. with webrev at, http://cr.openjdk.java.net/~hb/8007141/webrev.00/ Appreciate if I can get inputs for below. 1. Location of HotSpotPerfCounterMBean. It is located at

Re: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22

-Original Message- From: Amit Sapre Sent: Thursday, February 23, 2017 11:55 AM To: David Holmes; serviceability-dev@openjdk.java.net; Harsha Wardhana B Subject: RE: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 Hello, In a messy run of this test case, the

Re: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris

Thanks for the review Daniel. -Harsha On Wednesday 22 February 2017 08:21 PM, Daniel Fuchs wrote: Hi Harsha, OK - makes sense to me. Maybe just wait for tomorrow to see if you get any other comments form other reviewers... best regards, -- daniel On 22/02/17 14:38, Harsha Wardhana B wrote

Re: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris

es in anyway as test cases rely on delegation of specific permissions. Regards Harsha On Wednesday 22 February 2017 07:43 PM, Daniel Fuchs wrote: Hi Harsha, Looks good - but do you really need java.lang.RuntimePermission "*" ? What permission was missing? best regards, -- daniel On

Re: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22

Hi Amit, There is no need to wait in a loop to check we have not received any notifications. Without starting the monitors, the listener count will be zero. The first part of diff L116-L121 could be left as is. By relying on Jtreg timeout for receiving notifications, we will be unable to pr

RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris

Hi All, Please review the below test fix for Issue: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ The fix does the following. 1. Removes explicit platform check 2.

Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port

Hi Roger, Your approach is more elegant. However checking for ":0/" may not work as we can have non-zero port number that can end in 0. Regards Harsha On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: Hi Harsha, On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: Hi

Re: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact"

Looks fine. On Fri, Jan 13, 2017 at 1:56 PM +0530, "Ujwal Vangapally" wrote: kindly review the fix for bug JDK-8024352 Bug Id : https://bugs.openjdk.java.net/browse/JDK-8024352 webrev : http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8024352/webrev.00/ Thanks, Ujwa

Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port

Hi Amit, In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx url. JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked before accessing index at token[6]. It is possible that port number need not always be present at given index and hence we may have to follow d

Re: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip

ut Roger. Fred On 11/18/2016 10:32 AM, Harsha Wardhana B wrote: Hi Roger, I was not sure about adding exitVM.* as that would give permissions for all exit codes. Maybe Fred can comment since he is the test case author. -Harsha On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: Hi Harsha

Re: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip

hanges its exit status. Roger On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: Hello All, Please review below fix for issue https://bugs.openjdk.java.net/browse/JDK-8169575 having webrev at, http://cr.openjdk.java.net/~hb/8169575/webrev.00/ Regards Harsha

RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip

Hello All, Please review below fix for issue https://bugs.openjdk.java.net/browse/JDK-8169575 having webrev at, http://cr.openjdk.java.net/~hb/8169575/webrev.00/ Regards Harsha

Re: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

Hello, Gentle reminder !! -Harsha On Tuesday 15 November 2016 02:16 PM, Harsha Wardhana B wrote: Hello, Please review below webrev incorporating Daniel's comments. http://cr.openjdk.java.net/~hb/8141591/webrev.01/ Regards Harsha On Monday 14 November 2016 04:14 PM, Daniel Fuchs

Re: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

Hello, Please review below webrev incorporating Daniel's comments. http://cr.openjdk.java.net/~hb/8141591/webrev.01/ Regards Harsha On Monday 14 November 2016 04:14 PM, Daniel Fuchs wrote: On 14/11/16 06:57, Harsha Wardhana B wrote: Well, that will not cover the case where user shuts

Re: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

Hi Daniel, On Friday 11 November 2016 11:02 PM, Daniel Fuchs wrote: On 11/11/16 16:57, Harsha Wardhana B wrote: Hi Daniel, Old executor will be shutdown by the user. We are only swapping a user supplied executor with new linear executor. It will follow the same shutdown sequence as original

Re: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

my changes. I haven't JPRT yet but would be happy to share test results if required. best regards, -- daniel On 11/11/16 16:02, Harsha Wardhana B wrote: Hello, Please review the fix for issue : https://bugs.openjdk.java.net/browse/JDK-8141591 webrev : http://cr.openjdk.java.net/~hb/81

RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

Hello, Please review the fix for issue : https://bugs.openjdk.java.net/browse/JDK-8141591 webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ Fix details: The root-cause for the issue is that NotifFetcher thread was suspended at L562 after which main thread ran to completion shutting

Re: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received!

Looks good. -Harsha On Monday 07 November 2016 09:08 PM, Ujwal Vangapally wrote: Gentle remainder Thanks, Ujwal. On 11/4/2016 4:33 PM, Ujwal Vangapally wrote: Please review this small change for the bug below https://bugs.openjdk.java.net/browse/JDK-8168141 Webrev: http://cr.openjdk.ja

Re: RFR: JDK-8068155: [Findbugs]new sun.jvm.hotspot.utilities.ObjectReader() creates a sun.jvm.hotspot.utilities.ProcImageClassLoader classloader, which should be performed within a doPrivileged block

Hello, It is not required that SA should be run under security manager to address this change. Any standalone application when run under security manager can use ObjectReader class to exploit vulnerabilities. That is something that should be evaluated. With the below fix any application when

Re: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c

Thanks for the review, Dmitry. Harsha On Tuesday 06 September 2016 12:27 PM, Dmitry Samersoff wrote: Harsha, OK. The fix looks good for me. -Dmitry On 2016-09-06 09:49, Harsha Wardhana B wrote: Dmitry, The scope of the issue was to fix parfait warnings though I have gone to some extent

  1   2   >