Question on jmh.lock

[Alun Evans]

Hi Aleksey,

> On 12 Jan 2016, at 10:46, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Hi,
> 
> It's unclear if you actually run into the problem with this mechanism?

Sorry, yes I have, I’m hitting a permissions problem:

[alun at poweredge ~]$ ll /tmp/jmh.lock
-rw-rw-r--. 1 misha misha 0 Jan 11 20:26 /tmp/jmh.lock
[alun at poweredge ~]$ rm /tmp/jmh.lock
rm: remove write-protected regular empty file `/tmp/jmh.lock'? y
rm: cannot remove `/tmp/jmh.lock': Operation not permitted
[alun at poweredge ~]$

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.xockets.InterfaceBenchmark
[INFO] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.081 sec <<< FAILURE! - in com.xockets.InterfaceBenchmark
[INFO] run(com.xockets.InterfaceBenchmark)  Time elapsed: 0.079 sec  <<< ERROR!
[INFO] org.openjdk.jmh.runner.RunnerException: ERROR: Exception while trying to acquire the JMH lock (/tmp/jmh.lock): /tmp/jmh.lock (Permission denied), exiting. Use -Djmh.ignoreLock=true to forcefully continue.
[INFO]  at org.openjdk.jmh.runner.Runner.run(Runner.java:209)
[INFO]  at com.xockets.AbstractBenchmark.run(AbstractBenchmark.java:92)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)


> On 01/12/2016 08:55 PM, Alun Evans wrote:
>> This java.io.tmp + jmh.lock doesn’t seemed to be deleted at the end
>> of a test run, meaning that when a different user comes to run the
>> test, the file already exists.
> 
> It's irrelevant that a file exists, what matters is that we are
> java.nio.channels.FileLock-ing it. Note that this is different from
> "file locking" that shell scripts do: write out the tombstone file, then
> remove it at the end; plus always check for the existence of the
> tombstone file on entry.
> 
> Therefore, it is irrelevant that jmh.lock file is kept after JMH exits.
> If that was a problem, then consecutive JMH invocation by the same user
> would not also work.

I think the permissions on the file aren’t right for a subsequent different user to be able to FileLock it?

>> I was debating setting `java.io.tmp` to something else, but I think
>> that the goal is that only 1 user per machine should really be
>> running a JMH test at the same time, so it’s probably just better to
>> cleanup the lock file ?
> 
> The intent was to disallow accidental JMH session when other session is
> already running (think running JMH from the IDE). The side effect of
> disallowing concurrent JMH runs on the entire machine is a nice special
> case, and I think we should continue doing that.

Yes, it does make sense to me.

I’ve been developing inside a VM, but then when we want *actual* numbers, we need to run it on a bare metal machine.


thanks,


A.

--
Alun Evans