JDK-8193391 : Unable to acquire the JMH lock
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2017-05-11
  • Updated: 2018-06-28
  • Resolved: 2018-06-28
Related Reports
Relates :  
Relates :  
Relates :  
Description
A bunch of tests all failed in the same way:

[2017-05-10T15:29:51.35] # Actual: /export/local/aurora/CommonData/TEST_JAVA_HOME/bin/java -Xcomp -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation org.openjdk.jmh.Main -f 1 oracle.micro.benchmarks.api.java.nio.ByteBuffers.testByteBufferSingleGetDouble
[2017-05-10T15:29:51.35] 
[2017-05-10T15:30:06.18] ERROR: org.openjdk.jmh.runner.RunnerException: ERROR: Unable to acquire the JMH lock (/tmp/jmh.lock): already taken by another JMH instance, exiting. Use -Djmh.ignoreLock=true to forcefully continue.
[2017-05-10T15:30:06.23] 	at org.openjdk.jmh.runner.Runner.run(Runner.java:202)
[2017-05-10T15:30:06.23] 	at org.openjdk.jmh.Main.main(Main.java:71)

Comments
Based on the intended purpose of /tmp/jmh.lock, resolving this as Not an Issue.
28-06-2018

Re-reading the comments, I don't think this is a JDK issue. Instead it sounds like an attempt to run two instances of JMH at the same time so more time.
01-03-2018

Per Aleksey's comment it looks as if this bug could be resolved as "Not an Issue."
12-12-2017

So, does /tmp/jmh.lock actually exist? What are the file attributes? JMH has this to avoid running several JMH instances on one machine by accident. If performance is the purpose for the run, that is a valid failure. If tests are run for functional testing, then use -Djmh.ignoreLock=true, as the error message says.
07-12-2017

Yes, this looks like a JMH problem.
05-09-2017

Should this be transferred to the JMH project?
04-09-2017