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?
