Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch the extension registry again when delegate command handler not found #2184

Merged
merged 1 commit into from
Aug 11, 2022

Conversation

jdneo
Copy link
Contributor

@jdneo jdneo commented Aug 5, 2022

  • fetch the extension registry again when delegate command handler cannot be found.
  • change WorkspaceExecuteCommandHandler to Bill Pugh Singleton (thread safe).

Background

Our extension's BI shows that there are some no delegateCommandHandler errors. It's hard to stably reproduce but looking into the code, looks that we have some issues under the concurrent scenarios.

For example, when a command starts to find its delegator before it's added via public synchronized void added(IExtension[] extensions).

This case can be easily reproduced in debug mode:

  1. set a break point in the entry of public synchronized void added(IExtension[] extensions)
  2. Launch JDT.LS and open https://github.com/spring-projects/spring-petclinic/blob/main/src/main/java/org/springframework/samples/petclinic/PetClinicApplication.java
  3. There are some chances that the local cache is out-of-sync (the variable candidates is empty after filtering), since the breakpoint postpone the handler registration into the cache.

Signed-off-by: Sheng Chen sheche@microsoft.com

Copy link
Contributor

@rgrunber rgrunber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't able to get added(..) to trigger, but I suppose if the set of candidates really is empty, it couldn't hurt to try re-loading.

- fetch the extension registry again when delegate command handler
  cannot be found.
- change WorkspaceExecuteCommandHandler to Bill Pugh Singleton.

Signed-off-by: sheche <sheche@microsoft.com>
@rgrunber rgrunber merged commit 3fb4db7 into eclipse-jdtls:master Aug 11, 2022
@rgrunber rgrunber added this to the End August 2022 milestone Aug 11, 2022
@rgrunber rgrunber added the bug label Aug 11, 2022
@jdneo jdneo deleted the cs/noDelegateCommand branch August 12, 2022 01:29
@rgrunber
Copy link
Contributor

@jdneo , was this fix likely a result of microsoft/vscode#161563 ? I'm guessing that was the root cause.

@jdneo
Copy link
Contributor Author

jdneo commented Sep 24, 2022

Yes, we did some tests about the bundle registration recently, and found that the root cause is that some bundle file locations are not sent from client to server at the beginning (extension.all does not contain those extensions at first, those missing extensions are discovered later by VS Code).

If we want to address this on our side, a possible solution might be when the client received an extension did change event, send some kind of refresh bundle request to the server. This means the server will allow to install bundles not only in the initialization phase, but anytime actually. (One more benefit is that we may say goodbye to reloading VS Code when new Java extension is installed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants