[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out
From:       Daniil Titov <daniil.x.titov () oracle ! com>
Date:       2018-12-22 2:04:43
Message-ID: 0B661A5C-E59D-481C-BC3B-0951621F1F51 () oracle ! com
[Download RAW message or body]

Hi David and Serguei,

Please review a new version of the fix that for Linux platform uses the proc \
filesystem to retrieve the main class name for the running Java process. 

Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 

Thanks,
Daniil

On 11/29/18, 4:52 PM, "David Holmes" <david.holmes@oracle.com> wrote:

    Hi Daniil,
    
    On 30/11/2018 7:30 am, Daniil Titov wrote:
    > Thank you, David!
    > 
    > The proposed fix didn't help. It still hangs at some occasions.  Additional \
tracing showed that when jcmd is invoked with the main class name it iterates over \
all running Java processes and temporary attaches to them to retrieve the main class \
name. It hangs while trying to attach to one of the running Java processes. There are \
numerous Java processes running at the host machine some associated with the test \
framework itself and another with the tests running in parallel. It is not clear what \
exact is this particular process since the jcmd hangs before retrieving the process' \
main class name, but after all tests terminated the process with this id is no longer \
running.  I have to revoke this review since more investigation is required.  
    That sounds like an unsolvable problem for the test. You can't control 
    other Java processes on the machine, and searching by name requires 
    asking each of them in turn.
    
    How do we get the list of Java processes in the first place? Perhaps we 
    need to do some /proc/<pid>/cmdline peeking?
    
    Cheers,
    David
    
    > 
    > Best regards,
    > Daniil
    > 
    > 
    > 
    > On 11/11/18, 1:35 PM, "David Holmes" <david.holmes@oracle.com> wrote:
    > 
    >      Hi Daniil,
    >      
    >      I took a quick look at this one ... two minor comments
    >      
    >      The static class names could just be "Process" as they will acquire the
    >      enclosing class name as part of their own name anyway. As it is this
    >      gets repeated eg:
    >      
    >      HelpTest$HelpTestProcess
    >      InvalidCommandTest$InvalidCommandTestProcess
    >      
    >      TestJavaProcess.java:
    >      
    >      39     public static void main(String argv[]) {
    >      
    >      Nit: Should be "String[] argv" in Java style
    >      
    >      Thanks,
    >      David
    >      
    >      On 10/11/2018 3:18 PM, Daniil Titov wrote:
    >      > Please review the change that fixes serviceability/dcmd/framework/* \
tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* \
tests non-concurrent to ensure that they don't interact with each other and there are \
no multiple tests running simultaneously since all they do share the common main \
class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the  \
tests from other directories still might run in parallel with these tests and they \
also have com.sun.javatest.regtest.agent.MainWrapper as a main class.  >      >
    >      > The fix  ensures that each serviceability/dcmd/framework/* test uses a \
Java process with a unique main class name when connecting to this process with jcmd \
and the main class name.  >      >
    >      > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654
    >      > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/
    >      >
    >      > Best regards,
    >      > Daniil
    >      >
    >      >
    >      
    > 
    > 
    


[prev in list] [next in list] [prev in thread] [next in thread]