Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Hi Daniil, It looks good. I've consulted with Igor Ignatyev, and he suggested exactly the same approach. Thanks, Serguei On 3/13/18 22:26, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Confirming good to go. David On 15/03/2018 3:26 AM, Chris Plummer wrote: Hi Daniil, I believe David said he would defer to me on whether you should take the approach of spawning a different app to avoid this issue. I'm fine with it the way it is, so unless you feel compelled to take the more complicated approach, I think you're good to go. thanks, Chris On 3/14/18 9:47 AM, daniil.x.ti...@oracle.com wrote: Hi Chris and David, Could you please say is anything else required or you are OK with these changes? As Chris already replied there are only 3 tests that will be affected and each of them takes less than 5 seconds to complete. On 3/13/18 10:50 PM, Chris Plummer wrote: Hi Danill, The fix looks good. Were you able to reproduce this problem, and then after the fix run the tests enough times to be confident this really resolves the issue? I was able to reproduce this problem with Mach5 . There were about 1-3 failures per 100 runs of hotspot_serviceability suite. After the fix the tests were run more then 1000 times without failures. Are you going to close JDK-8194057 as a dup? Yes. I plan to close JDK-8194057 as a duplicate. thanks, Chris Thanks! Best regards, Daniil On 3/13/18 10:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Hi Daniil, I believe David said he would defer to me on whether you should take the approach of spawning a different app to avoid this issue. I'm fine with it the way it is, so unless you feel compelled to take the more complicated approach, I think you're good to go. thanks, Chris On 3/14/18 9:47 AM, daniil.x.ti...@oracle.com wrote: Hi Chris and David, Could you please say is anything else required or you are OK with these changes? As Chris already replied there are only 3 tests that will be affected and each of them takes less than 5 seconds to complete. On 3/13/18 10:50 PM, Chris Plummer wrote: Hi Danill, The fix looks good. Were you able to reproduce this problem, and then after the fix run the tests enough times to be confident this really resolves the issue? I was able to reproduce this problem with Mach5 . There were about 1-3 failures per 100 runs of hotspot_serviceability suite. After the fix the tests were run more then 1000 times without failures. Are you going to close JDK-8194057 as a dup? Yes. I plan to close JDK-8194057 as a duplicate. thanks, Chris Thanks! Best regards, Daniil On 3/13/18 10:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Hi Chris and David, Could you please say is anything else required or you are OK with these changes? As Chris already replied there are only 3 tests that will be affected and each of them takes less than 5 seconds to complete. On 3/13/18 10:50 PM, Chris Plummer wrote: Hi Danill, The fix looks good. Were you able to reproduce this problem, and then after the fix run the tests enough times to be confident this really resolves the issue? I was able to reproduce this problem with Mach5 . There were about 1-3 failures per 100 runs of hotspot_serviceability suite. After the fix the tests were run more then 1000 times without failures. Are you going to close JDK-8194057 as a dup? Yes. I plan to close JDK-8194057 as a duplicate. thanks, Chris Thanks! Best regards, Daniil On 3/13/18 10:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
On 14/03/2018 4:49 PM, Chris Plummer wrote: On 3/13/18 10:54 PM, David Holmes wrote: Hi Daniil, On 14/03/2018 3:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. It's good to finally find the root cause of the problem! The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. This seems more of a workaround than a fix - though I don't know whether there is a way to distinguish multiple VMs all running what appears to be the same main class. The three tests are all intentionally testing the "jcmd " functionality. A better fix (but not worth it IMHO) would be to spawn a separate test process rather than using the main test process, which is always going to share the main class name with other concurrently running tests. Yes uniquely named main classes would be better. I'll defer to you on the "worth it" part. My concern with the fix is how long it will take to run these tests sequentially, as they are run in tier2 and as part of the CI test job? They are quick tests and there are only 3 of them. They appear to take less than 5 seconds each. Great! Thanks Chris. David Chris Thanks, David Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
On 3/13/18 10:54 PM, David Holmes wrote: Hi Daniil, On 14/03/2018 3:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. It's good to finally find the root cause of the problem! The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. This seems more of a workaround than a fix - though I don't know whether there is a way to distinguish multiple VMs all running what appears to be the same main class. The three tests are all intentionally testing the "jcmd " functionality. A better fix (but not worth it IMHO) would be to spawn a separate test process rather than using the main test process, which is always going to share the main class name with other concurrently running tests. My concern with the fix is how long it will take to run these tests sequentially, as they are run in tier2 and as part of the CI test job? They are quick tests and there are only 3 of them. They appear to take less than 5 seconds each. Chris Thanks, David Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Hi Daniil, On 14/03/2018 3:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. It's good to finally find the root cause of the problem! The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. This seems more of a workaround than a fix - though I don't know whether there is a way to distinguish multiple VMs all running what appears to be the same main class. My concern with the fix is how long it will take to run these tests sequentially, as they are run in tier2 and as part of the CI test job? Thanks, David Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
Re: RFR 8166642: serviceability/dcmd/framework/* timeout
Hi Danill, The fix looks good. Were you able to reproduce this problem, and then after the fix run the tests enough times to be confident this really resolves the issue? Are you going to close JDK-8194057 as a dup? thanks, Chris On 3/13/18 10:26 PM, Daniil Titov wrote: Please review the changes that fix intermittent timeout failure of serviceability/dcmd/framework/* tests. The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166642 Webrev: http://cr.openjdk.java.net/~dtitov/8166642/webrev.01 The tests ran successfully with Mach5. Best regards, Daniil
