(apparent) Deadlock caused by RefreshDSLDJob #1066
Comments
|
I will have a look. Would it be possible for you to provide a minimal project setup that still runs into this issue? You can completely disable DSLD support in your workspace preferences: Or you can add this to your eclipse.ini You can also go the nuclear route and remove the DSLD bundle entirely from your installation. It is entirely optional and is loosely coupled through eclipse's extension mechanisms. |
|
So your UI is freezing up while trying to display hover information. Groovy is a search participant and tries to do its part to answer a search request. While trying to understand a GroovyCompilationUnit (groovy source of some kind) it is waiting for DLSDTypeLookup to be ready. As you mentioned, the RefreshDSLDJob is running in another thread and is waiting to get the package fragment roots (libraries and source folders) of the project. I think the request for package fragment roots is more expensive in your environment due to LSP latencies. I will do a little more looking to understand the refresh interval and why the library info is slow or delayed. |
|
Thanks, I didn't know about the ability to disable DSLD support at workspace level, I don't think I need it (I just use Groovy besides Java in my Java and Dynamic Web Projects).
Unfortunately I don't think I would be able to do so: it's a huge (proprietary) project, with 3 Dynamic Web Projects and one Utility Module. 2 out of 3 Dynamic Web Projects use JSF/Prime Faces. I wouldn't even know which parts of the codebase would be actually needed to reproduce :-( |
|
Here is the code for getting project classpath (so DSLDs can be scanned for). It has a bit of a sordid history: /**
* Get all package fragment roots in a safe way so that concurrent modifications aren't thrown (GRECLIPSE-1284).
*/
private IPackageFragmentRoot[] getFragmentRoots(final IProgressMonitor monitor) throws JavaModelException {
final IPackageFragmentRoot[][] roots = new IPackageFragmentRoot[1][];
try {
ResourcesPlugin.getWorkspace().run(pm -> {
roots[0] = JavaCore.create(project).getAllPackageFragmentRoots();
}, getSchedulingRule(), IWorkspace.AVOID_UPDATE, monitor);
} catch (CoreException e) {
if (e.getStatus().getCode() == IJavaModelStatusConstants.ELEMENT_DOES_NOT_EXIST) {
// ignore...project was deleted
} else {
GroovyDSLCoreActivator.logException(e);
}
}
return roots[0] != null ? roots[0] : new IPackageFragmentRoot[0];
}
private ISchedulingRule getSchedulingRule() {
IResourceRuleFactory ruleFactory = ResourcesPlugin.getWorkspace().getRuleFactory();
// FIXADE Arrrrgh...we need to grab a build rule here. Looks like a classpath container refresh
// will grab the rule of projects that are contained in the container.
/*return new MultiRule(new ISchedulingRule[] {
// use project modification rule as this is needed to create the .classpath file if it doesn't exist yet, or to update project references
ruleFactory.modifyRule(this.project.getProject()),
// and external project modification rule in case the external folders are modified
ruleFactory.modifyRule(JavaModelManager.getExternalManager().getExternalFoldersProject())
});*/
return ruleFactory.buildRule();
} |
|
IWorkspaceRunnable instances that are used to run stuff asynchronously are managed so that only one is running for a given scheduling rule. LSP4e uses them to update markers (seen in your thread dump): https://git.eclipse.org/r/plugins/gitiles/lsp4e/lsp4e/+/master/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/diagnostics/LSPDiagnosticsToMarkers.java#141 You could file a bug with lsp4e as well. If they changed "run(runnable, ...)" to "run(runnable, resource, IWorkspace.AVOID_UPDATE, ...)", it would reduce the scope of their job. |
|
ready to test |
|
I installed 3.7.0.v202003252328-e1912 and re-enabled DSLD support in my workspace, I'll let you know how it goes, thank you. |
When editing facelets (JSF .xhtml files), my Eclipse IDE UI often freezes for dozen seconds, if not even minutes. Today it seemed to be hung for so long that I thought it was a deadlock.
I decided to took a thread dump and discovered that the cause of this was a search probably triggered for EL expressions that was triggering the
DSDLStoreManagerthat was in turn waiting for something to complete, probably theRefreshDSLDJobjob.After some minutes, the IDE UI was responsive again, but this problem is really frustrating and hurts productivity a lot.
Please note that DSL support in classpath is disabled for this project. I don't use DSLs, so these "refreshing DSLD" jobs that often show up are somewhat irritating, especially when they hang the IDE like in this case. Is there a way to shut down this DSLD thing completely? What is needed for? I only have Gradle build files in my projects, for which support in the editor is very limited anyway.
Please note that my CPU was not very busy while this apparent deadlock was "running", so it's not quite clear to me why this job takes so much time.
Here is a thread dump:
threaddump-1585131180093.tdump.txt
The text was updated successfully, but these errors were encountered: