LingeredApp termination sequence

[Gary Adams]

The problem I was trying to understand a little better ...

I was observing an IOException, but it was not a NoSuchFileException.
Changing to catch just IOException runs cleanly, but may obscure
some other cause of the IOException.

Testing a variant today that exits cleanly as long as the lock file was 
removed.

diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java 
b/test/lib/jdk/test/lib/apps/LingeredApp.java
--- a/test/lib/jdk/test/lib/apps/LingeredApp.java
+++ b/test/lib/jdk/test/lib/apps/LingeredApp.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -492,18 +492,21 @@
          }

          String theLockFileName = args[0];
+        Path path = Paths.get(theLockFileName);

          try {
-            Path path = Paths.get(theLockFileName);
-
              while (Files.exists(path)) {
                  // Touch the lock to indicate our readiness
                  setLastModified(theLockFileName, epoch());
                  Thread.sleep(spinDelay);
              }
-        } catch (NoSuchFileException ex) {
+        } catch (IOException ex) {
              // Lock deleted while we are setting last modified time.
-            // Ignore error and lets the app exits
+            // Ignore the error and let the app exit.
+            if (Files.exists(path)) {
+                // If the lock file was not removed, return an error.
+                System.exit(4);
+            }
          } catch (Exception ex) {
              System.err.println("LingeredApp ERROR: " + ex);
              // Leave exit_code = 1 to Java launcher


During the latest set of test runs I saw a variety of RMI binding errors.
These could be issues with the test infrastructure systems.
Or could be collisions from the test harness.

[Jstatd-Thread] Could not bind /JStatRemoteHost to RMI Registry
[Jstatd-Thread] java.rmi.server.ExportException: Port already in use: 
1099; nested exception is:
[Jstatd-Thread]     java.net.BindException: Address already in use: NET_Bind
[Jstatd-Thread]     at 
java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)


[Jstatd-Thread] Could not bind //:49153/JStatRemoteHost to RMI Registry
[Jstatd-Thread] java.rmi.ConnectIOException: error during JRMP 
connection establishment; nested exception is:
[Jstatd-Thread]     java.net.SocketTimeoutException: Read timed out


[Jstatd-Thread] Could not bind //:33712/JStatRemoteHost to RMI Registry
[Jstatd-Thread] java.rmi.server.ExportException: Port already in use: 
33712; nested exception is:
[Jstatd-Thread]     java.net.BindException: Address already in use (Bind 
failed)


[Jstatd-Thread] Could not bind //:58765/TestJstatdServer to RMI Registry
[Jstatd-Thread] java.rmi.ConnectIOException: Exception creating 
connection to: 10.133.156.143; nested exception is:
[Jstatd-Thread]     java.net.NoRouteToHostException: Cannot assign 
requested address


On 3/30/19, 9:46 AM, Dmitry Samersoff wrote:
> Hello Gary,
>
> The LingeredApp was designed to provide precise control over the life
> cycle of a subordinate process.
>
> This means that if the app exits unexpectedly, we should have detailed
> information why it happens.
>
> IOException may occur when the app tries to touch lockfile (e.g. due to
> a network filesystem error), so it might be better to catch IOException,
> then check if it is an instance of NoSuchFileException or the lockfile
> was deleted by driver.
>
> -Dmitry
>
> On 29.03.2019 20:12, Gary Adams wrote:
>> While running some bulk testing on jdk/sun/tools I've
>> come across some errors reported from the termination sequence
>> for LingeredApp debuggee process.
>>
>> The main process creates a locking file, which the LingeredApp
>> sits in a loop updating the file modification date. When the main
>> test completes it stops the LingeredApp by removing the file.
>>
>> The clean exit results when LingeredApp gets a NoSuchFileException.
>> I see a number of bugs filed that are getting a raw IOException
>> on the LingeredApp termination.
>>
>> I'm going to attempt to get more specific information about the
>> IOException.
>>
>> diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java
>> b/test/lib/jdk/test/lib/apps/LingeredApp.java
>> --- a/test/lib/jdk/test/lib/apps/LingeredApp.java
>> +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java
>> @@ -504,6 +504,9 @@
>>           } catch (NoSuchFileException ex) {
>>               // Lock deleted while we are setting last modified time.
>>               // Ignore error and lets the app exits
>> +        } catch (IOException ioe) {
>> +            ioe.printStackTrace();
>> +            System.exit(3);
>>           } catch (Exception ex) {
>>               System.err.println("LingeredApp ERROR: " + ex);
>>               // Leave exit_code = 1 to Java launcher
>>
>> Since the error is being detected as the test is terminating,
>> I think it would be possible to simply replace the NoSuchFileException,
>> and consider an IOException as the trigger for the clean exit sequence.
>>
>> Anyone have experience with this corner of the swamp?
>>