apache/accumulo-testing

Missing Jar during Randomwalk

Opened this issue · 9 comments

While running the MultiTable RW module, I saw it die due to this exception.

2022-02-17T15:19:19,515 [testing.randomwalk.Framework] INFO : Test finished
Exception in thread "Thread-3" java.lang.RuntimeException: java.nio.file.NoSuchFileException: /home/mike/workspace/accumulo-testing/target/dependency/hadoop-client-api.jar
	at org.apache.hadoop.conf.Configuration.loadResource(Configuration.java:3037)
	at org.apache.hadoop.conf.Configuration.loadResources(Configuration.java:2984)
	at org.apache.hadoop.conf.Configuration.loadProps(Configuration.java:2864)
	at org.apache.hadoop.conf.Configuration.getProps(Configuration.java:2846)
	at org.apache.hadoop.conf.Configuration.get(Configuration.java:1200)
	at org.apache.hadoop.conf.Configuration.getTimeDuration(Configuration.java:1812)
	at org.apache.hadoop.conf.Configuration.getTimeDuration(Configuration.java:1789)
	at org.apache.hadoop.util.ShutdownHookManager.getShutdownTimeout(ShutdownHookManager.java:183)
	at org.apache.hadoop.util.ShutdownHookManager.shutdownExecutor(ShutdownHookManager.java:145)
	at org.apache.hadoop.util.ShutdownHookManager.access$300(ShutdownHookManager.java:65)
	at org.apache.hadoop.util.ShutdownHookManager$1.run(ShutdownHookManager.java:102)
Caused by: java.nio.file.NoSuchFileException: /home/mike/workspace/accumulo-testing/target/dependency/hadoop-client-api.jar
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
	at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
	at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
	at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
	at java.base/java.nio.file.Files.readAttributes(Files.java:1764)
	at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1259)
	at java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:831)
	at java.base/java.util.zip.ZipFile$CleanableResource$FinalizableResource.(ZipFile.java:857)
	at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:846)
	at java.base/java.util.zip.ZipFile.(ZipFile.java:248)
	at java.base/java.util.zip.ZipFile.(ZipFile.java:177)
	at java.base/java.util.jar.JarFile.(JarFile.java:350)
	at java.base/sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:103)
	at java.base/sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:72)
	at java.base/sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
	at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:125)
	at java.base/sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:155)
	at org.apache.hadoop.conf.Configuration.parse(Configuration.java:2957)
	at org.apache.hadoop.conf.Configuration.getStreamReader(Configuration.java:3053)
	at org.apache.hadoop.conf.Configuration.loadResource(Configuration.java:3011)
	... 10 more

Did you run the build script or did the rwalk script run the build script? That is what creates the jar and that dependency directory. I confirmed on my end, that the jar creation takes place on the latest commit.

Did you run the build script or did the rwalk script run the build script?

I did not run the build script manually.

I saw this again and after doing a build in testing, there is no jar:
accumulo-testing/target/dependency/hadoop-client-api.jar

The directory ../target/dependency does not exist. This is created by the shaded jar build:

[INFO] --- maven-dependency-plugin:3.1.2:copy-dependencies (default-cli) @ accumulo-testing ---
[INFO] Copying hadoop-client-api-3.2.2.jar to /home/mike/workspace/accumulo-testing/target/dependency/hadoop-client-api.jar
[INFO] Copying hadoop-client-runtime-3.2.2.jar to /home/mike/workspace/accumulo-testing/target/dependency/hadoop-client-runtime.jar

So this could be happening if a build occurred but the shaded jar didn't get built.

So this could be happening if a build occurred but the shaded jar didn't get built.

For reference, the shaded jar doesn't get built by default, it requires -Pcreate-shade-jar to activate that profile. The bin/performance script and conf/env.sh both activate this profile.

@milleruntime Is there anything actionable to be done on this issue?

I think the actionable thing is that if randomwalk requires the shaded jar, it might need to build it itself, or have instructions to build it.

I think the actionable thing is that if randomwalk requires the shaded jar, it might need to build it itself, or have instructions to build it.

The rwalk script already calls source "${bin_dir}/build" so I am not sure there is anything to be done.

Is it possible that build script won't build the shaded jar if there's another jar that's already present? If so, that could be fixed. Otherwise, yeah, there might not be anything to do here.

Is it possible that build script won't build the shaded jar if there's another jar that's already present? If so, that could be fixed. Otherwise, yeah, there might not be anything to do here.

That is correct. The build script will not re-build the jars if they are currently present. However, I haven't really run into the original issue in my testing. I can see there being a possible benefit to echo to the shell if the jar is present so a user could be more aware that they may have old jars present.