Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] [jgit-dev] release 5.13.0
On Tue, Sep 14, 2021 at 1:51 AM Mark Waite <mark.earl.waite@xxxxxxxxx> wrote:
Dependabot detected a tag for JGit 5.13.0.  I've updated the Jenkins git client plugin to use JGit 5.13.0 in my test environment.

A new logging stack trace is being reported in the Jenkins git client plugin automated tests.  The stack trace is:

Sep 13, 2021 11:15:23 PM org.eclipse.jgit.internal.storage.file.LockFile unlock
SEVERE: Unlocking LockFile '/tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock' failed
java.io.IOException: Could not delete file /tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock
	at org.eclipse.jgit.util.FileUtils.handleDeleteException(FileUtils.java:232)
	at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:194)
	at org.eclipse.jgit.internal.storage.file.LockFile.unlock(LockFile.java:545)
	at org.eclipse.jgit.internal.storage.file.GcLog.unlock(GcLog.java:110)
	at org.eclipse.jgit.internal.storage.file.GC.lambda$0(GC.java:250)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.nio.file.NoSuchFileException: /tmp/junit14445476736651226115/junit15588760822522442699/.git/gc.log.lock
	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.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
	at java.base/java.nio.file.Files.delete(Files.java:1142)
	at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:191)
	... 8 more

The stack trace surprises me, since a "no such file exception" when attempting to remove a lock file seems like it should not be logged as SEVERE.  If the lock file is gone, the lock has been released.  The logic at that location in org.eclipse.jgit/src/org/eclipse/jgit/util/FileUtils.java in the delete(File f, int options) method is more than I'm able to immediately understand.  Anyone have any insights to offer?

If gc runs in the background it writes errors which may occur during execution to a file "gc.log".
The same file is used to create a file lock to guard gc against being executed by more than one thread/process concurrently.
GC#gc creates this file lock here [1] and expects it to be held until [2]. If the file lock is gone prematurely this means that 
eventually more than one thread/process could have had the chance to run gc concurrently which should not happen.
I think this warrants logging this with priority "severe".


-Matthias


Mark Waite

On Tue, Sep 7, 2021 at 2:53 PM Mark Waite <mark.earl.waite@xxxxxxxxx> wrote:


On Tue, Sep 7, 2021 at 2:12 PM Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
Mark Waite <mark.earl.waite@xxxxxxxxx> wrote on Mo., 6. Sep. 2021, 18:53:
I'd prefer that December be 5.14 because the Jenkins project is not ready to abandon Java 8 yet and I believe that JGit 6.0 plans to drop Java 8.

I don't think there's anything forcing Jenkins or Jenkins plug-ins to use JGit 6.0 if they currently use 5.x and that works. So I don't quite understand the reasoning here.


Agreed that there is nothing forcing Jenkins to use JGit 6.0.  We'll remain with the 5.x line until Jenkins is ready to drop Java 8 support.  If past history is an indicator, that will be at least another 1-2 years.

I fully support the JGit project choosing their own timeline when they drop support for Java 8.

Jenkins has suffered some pain in the past when we allowed ourselves to fall behind the JGit development path.  The upgrade from JGit 4 to JGit 5 was quite laborious for the Jenkins git client plugin because it had to "catch up" across several minor versions and it had to resolve different API compatibility models used in JGit than are used in Jenkins.  There is nothing wrong with either of the API compatibility models, they are just different and the difference brought some complications.

Mark Waite
 
Personally, either is fine with me. When we do JGit 6.0 Java 11 based, EGit 6.0 will follow suit and will bump its baseline to Eclipse 2020-09. (First Eclipse version that required Java 11.)

Cheers,

  Thomas
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jgit-dev
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jgit-dev

Back to the top