Bug 437855 - classloader leak due to JGit-AlarmQueue
Summary: classloader leak due to JGit-AlarmQueue
Status: NEW
Alias: None
Product: JGit
Classification: Technology
Component: JGit (show other bugs)
Version: 3.4   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-21 08:10 EDT by Andrei Pozolotin CLA
Modified: 2017-05-26 05:58 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Pozolotin CLA 2014-06-21 08:10:38 EDT
despite an attempt here
https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/lib/BatchingProgressMonitor.java#L58

JGit-AlarmQueue still keeps the application classloader pinned via
* Thread.inheritedAccessControlContext
* Thread.inheritableThreadLocals
* Thread.contextClassLoader

my current workaround is explicit "stop" before application unload,
this does release the class loader:

	public static void stop() throws Exception {
		try {

			final Field field = BatchingProgressMonitor.class
					.getDeclaredField("alarmQueue");

			field.setAccessible(true);

			final ScheduledThreadPoolExecutor alarmQueue = (ScheduledThreadPoolExecutor) field
					.get(null);

			alarmQueue.shutdownNow();

		} catch (final Throwable e) {
			logger.error("Failed to stop.", e);
		}
	}


a better solution?
I would rather have a public Git.shutdown()
to release all threads, NLS, etc. rather the trying to outsmart 
the vm/classloader gc logic
Comment 1 Jochen Kemnade CLA 2017-05-26 05:58:51 EDT
Definitely in favor of a shutdown method. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=449321, https://bugs.eclipse.org/bugs/show_bug.cgi?id=517107