CloseableBundleFile with reentrant locking mechanism

[rahulsh1]

While looking at the code for CloseableBundleFile, I see that this class manages access to bundle files, ensuring they are properly opened and closed. It uses a lock to control access and a reference count to track open input streams.

If osgi.bundlefile.limit=0 is used, preventing the bundle file from being closed after being opened until the JVM is up, is the locking mechanism still necessary, considering that the access to the bundle contents is 'read-only'?"

If the primary function of the CloseableBundleFile class is to manage the number of open bundle files by using the MRUBundleFileList, would removing the locking still guarantee correct functioning?

One reason for this is we are seeing stuck threads in the JVM waiting to acquire the lock, see below:

java.lang.Thread.State: WAITING (parking)
     at jdk.internal.misc.Unsafe.park(java.base@17.0.11.0.103/Native Method)
     - parking to wait for  <0x00000006165dea20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
     at java.util.concurrent.locks.LockSupport.park(java.base@17.0.11.0.103/LockSupport.java:211)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11.0.103/AbstractQueuedSynchronizer.java:715)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.11.0.103/AbstractQueuedSynchronizer.java:938)
     at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base@17.0.11.0.103/ReentrantLock.java:153)
     at java.util.concurrent.locks.ReentrantLock.lock(java.base@17.0.11.0.103/ReentrantLock.java:322)
     at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.lockOpen(CloseableBundleFile.java:81)
     at org.eclipse.osgi.storage.bundlefile.CloseableBundleFile.getEntry(CloseableBundleFile.java:285)

I see there was a commit to make sure the lockOpen is released on unexpected errors and likely we are also running into something similar.
We are already on 3.22.0

Looking for suggestions to debug the issue and/or inputs on removing the locking mechanism.

[tjwatson]

Do you see the issue if you don't set osgi.bundlefile.limit=0?

The locking is needed even when osgi.bundlefile.limit=0 is set because the framework lazily opens the JARs for the bundle file. The lock is used to protect the lazy open operation. Have you tried getting a JVM stack dump when the hang occurs to see what threads may be hold the lock?

[rahulsh1]

Thanks for the reply.
Not setting osgi.bundlefile.limit=0 results in a significant application startup delay.
The issue is intermittent and not easily detected making it bit tricky to gather a stack dump. Also normal stack dump (without locking data that cannot be captured for performance reasons) does not reveal information on which thread holds the CloseableBundleFile reentrant lock.

[tjwatson]

Looking at the code, so far I don't see how the lock could be getting escaped like the unexpected errors fix addressed. Therefore a simple stack dump without locking data will at least let us see if any threads are blocked for some reason inside a block of code where we expect the lock to be held.

[rahulsh1]

If the lock gets leaked, there is no thread stack in the dump that shows this data, just threads waiting to acquire the bundle locks. This is consistently seen across multiple thread stack dumps.

[basilevs]

I observe org.eclipse.core.runtime.FileLocator.toFileURL() fighting for the lock with org.eclipse.core.runtime.FileLocator.find() this blocks UI in my application. However, the traces clearly show the problem, so this may be a different scenario.

In my case, the root cause is extracting large files from within bundle's JARs in a background thread and using DialogSettingsProvider in parallel from UI thread, blocking UI. The solution may be either to use Eclipse-BundleShape: dir, to use alternative form of large files delivery or not to store large files in UI plugins.