#2168 Synchronizing extraction of pluggable transports on class to avoid...

[oxtoacart]

... race condition in extracting file

[coveralls]

Coverage increased (+0.26%) when pulling 154e95d on 2168 into f4079ac on issue-2164.

[myleshorton]

I would consider using FileLock in LanternUtils instead, as it would solve the problem more generally and would isolate the locking to the file itself.

[oxtoacart]

Neat idea. Do you mean org.littleshoot.util.FileLockUtils ?

[myleshorton]

No java.nio.channels.FileLock directly -- something like

FileOutputStream out = new FileOutputStream(file);
try {
    java.nio.channels.FileLock lock = out.getChannel().lock();
    try {
        // move file in here.
    } finally {
        lock.release();
    }
} finally {
    in.close();
}

[oxtoacart]

Gotcha. And this is to prevent problems when running two instances of Lantern, right?

[myleshorton]

It's definitely a bit more verbose, but more robust I think too.

[myleshorton]

Gotcha. And this is to prevent problems when running two instances of Lantern, right?

Yeah, I'm basically thinking we just lock the flashlight file, although now that I think about it that'll just lock to the process not the thread -- maybe ignore me.

[oxtoacart]

although now that I think about it that'll just lock to the process not the thread

Correct. From the Javadoc for java.nio.channels.FileLock:

"File locks are held on behalf of the entire Java virtual machine. They are not suitable for controlling access to a file by multiple threads within the same virtual machine."

[myleshorton]

OK, let's just go with your solution. I'm always wary of synchronizing on a class, but I can't think of anything better here.

[oxtoacart]

Thanks!