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 DSDLStoreManager that was in turn waiting for something to complete, probably the RefreshDSLDJob job.
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
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