SonarLint Eclipse: Updating project bindings hangs on 100%


  • Eclipse IDE for RCP and RAP Developers version 2019-12 (4.14.0)
  • SonarLint Eclipse versions,

When SonarLint Eclipse updates project bindings, it hangs forever when it reaches 100%. It is not possible to cancel the task - it only displays (Cancel Requested), but the task stays there forever.
The issue affects many (if not all) developers in our team. We usually have more than 700 projects in workspace. Can the problem be caused by the workspace size or server settings?

Steps to reproduce:

  • Open the SonarLint Bindings view
  • Right-click the server
  • Select Update All Project Bindings


  • The only way to cancel the hanging update is to restart Eclipse.

Please tell if I have to provide more information or if I can assist in solving the problem in any other way.

Hi @htfv

Would it be possible for you to generate a thread dump, to have a stacktrace and find the location in our code where it is stuck?


Hello Julien,

Sure, here you go:

"Worker-21: Update SonarLint binding data from 'EDITED'" #3075 prio=5 os_prio=0 cpu=398703.13ms elapsed=1183.06s tid=0x0000028af72d1800 nid=0x136c runnable  [0x000000e3293fd000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.core.internal.preferences.ImmutableMap$ArrayMap.shareStrings(
        at org.eclipse.core.internal.preferences.EclipsePreferences.shareStrings(
        at org.eclipse.core.internal.preferences.EclipsePreferences.shareStrings(
        at org.eclipse.core.internal.preferences.EclipsePreferences.shareStrings(
        at org.eclipse.core.internal.preferences.EclipsePreferences.shareStrings(
        at org.eclipse.core.internal.preferences.PreferencesService.shareStrings(
        at org.eclipse.core.internal.preferences.PreferencesService.applyPreferences(
        at org.eclipse.core.internal.resources.ProjectPreferences.updatePreferences(
        at org.eclipse.core.internal.resources.File.updateMetadataFiles(
        at org.eclipse.core.internal.localstore.RefreshLocalVisitor.visit(
        at org.eclipse.core.internal.localstore.UnifiedTree.accept(
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(
        at org.eclipse.core.internal.resources.AliasManager.updateAliases(
        at org.eclipse.core.internal.resources.File.internalSetContents(
        at org.eclipse.core.internal.resources.File.setContents(
        at org.eclipse.core.internal.resources.ProjectPreferences.lambda$0(
        at org.eclipse.core.internal.resources.ProjectPreferences$$Lambda$1178/ Source)
        at org.eclipse.core.internal.preferences.EclipsePreferences.internalFlush(
        at org.eclipse.core.internal.resources.ProjectPreferences.flush(
        at org.sonarlint.eclipse.core.internal.SonarLintCorePlugin.saveConfig(
        at org.sonarlint.eclipse.core.internal.server.Server.lambda$23(
        at org.sonarlint.eclipse.core.internal.server.Server$$Lambda$1160/0x0000000801dd6c40.accept(Unknown Source)
        at java.util.ArrayList.forEach(java.base@13.0.2/
        at org.sonarlint.eclipse.core.internal.server.Server.updateProjectStorage(
        - locked <0x00000007415352d8> (a org.sonarlint.eclipse.core.internal.server.Server)
        at$$Lambda$1129/0x0000000801dbc840.accept(Unknown Source)
        at java.util.Optional.ifPresent(java.base@13.0.2/

   Locked ownable synchronizers:
        - None

What if you enable verbose output in the SonarLint console? Is the process really stuck, or just processing slowly? Do you see logs like:

Detected prefixes for <project>: [...]

Seems like it is going slowly. It prints the following lines once in ~10 seconds:

Detected prefixes for EDITED:
  IDE prefix: EDITED
  Server side prefix: EDITED

Good, that help. Could you please confirm if all the Eclipse projects are bound to the same SonarQube project?
Seems this SonarQube project has a lot of files (~15k). Is it correct?

There are more than 1300 Eclipse projects with more than 31000 Java files in single git repository. Developers usually have about 700-750 of those projects open in Eclipse, all of them connected to one SonarQube project.

Perfect, thanks for all the details. I think this is purely a performance issue of our algorithm that is used to auto-detect modules prefixes/suffixes.
I have created a ticket to improve that in the next version:

Thank you for quick response!