-
Notifications
You must be signed in to change notification settings - Fork 106
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
ElixirLS Running two instances on Vscode #125
Comments
It may be possible this has something to do with the latest macOS Catalina update. It was a major 3.5 gb update and I feel this may have started right after that. |
I haven't been able to reproduce this yet, although I only tried on one project on Catalina. Can you reproduce it on a public repository? (or create a repository that you can reproduce it on) |
Let me take a closer look during the weekend. I got it working normally today by enabling the extension on a per workspace basis instead of globally. |
How did you enable it on a per-workspace basis vs globally? |
@axelson I just individually enable it for the current Workspace for each of the codebases I work on. That's from the extensions panel in Vscode. |
I'm running Code-OSS on Arch Linux and it's happening to me too. I think we can rule out operating system. Are we only seeing this in umbrella projects by chance? I have a rather large umbrella project that this is happening in, but I spot checked a couple smaller (non-umbrella) elixir projects and it doesn't happen in any of those... |
I can't get it to happen on a fresh phoenix umbrella project: |
Got it! Steps to reproduce (shortcuts are for Linux, not sure what they are for mac):
Quitting the editor in this state and re-launching it using |
Thanks @doughsay, that's really helpful. I can confirm that closing all my unsaved files and restarting VSCode caused my duplicate ElixirLS instance to go away. |
@doughsay thanks for the detailed reproduction steps! That's very helpful and I am indeed able to replicate this issue.
That's very interesting and personally I wouldn't have ever expected that behavior although I can definitely see how it is helpful. I guess I've been trained by other software to never trust that an unsaved file will persist. As a side-note I never encountered this bug because I always create new elixir files by right-clicking the directory and typing the filename (e.g. I'm guessing that this bug was introduced in #70 and somewhat matches part of the description there:
But I would think that if an open file not belonging to a workspace but that is within the files already "watched" by an existing server, that a new server should not be spawned. @alex88 do you have any thoughts on a clean way to resolve this? |
@axelson I see the same behavior, however that's expected as the text you've quoted Update: it seems that the LS of the open file picks up the first workspace anyway (I see the DoubleDouble autocomplete), that's probably because that's the default path VSCode gives to the LS |
Alright, so, I've checked the initialization request that the LS receives, for both the workspace and the in-memory file the I've also tried to:
The elixir project works just fine, the in-memory file however starts the LS in the first workspace which also creates the I've then checked out version 0.4.0 (before the above changes) to see what the behavior was, doing the same steps as above. I've seen that the language server is started in the first workspace, so even if the first workspace isn't an elixir project, it gets "polluted" with the I think the main conflict at this point is that there are two LS instances using the same I see two possible solutions:
The first solution has the problem that it "pollutes" an unrelated folder (like 0.4.0 was doing), the second one that we just need to ensure we delete the temp folder when the LS is being terminated. What do you think? |
Thanks guys, good job figuring out the problem so quickly here! At least we know how to avoid it now while figuring out a permanent fix. |
How about,
|
FWIW, I vote for any solution that does still use the existing workspace for in-memory files. I use in-memory files as a scratch-pad and really do appreciate having my project's auto-complete available to me.
This seems reasonable to me! |
I have a slight concern about the logic of:
Since we reverted #107 in #115 can we be sure that when the first workspace does not have an instance running that it should not? Basically I'm worried about the case when the first workspace contains elixir files but no elixir files have been opened, for example the case where only Perhaps at that time we could do a search for an elixir file? And maybe we should only search the top-level of the workspace. Although it might be better to implement that as a re-introduction of #107 (without negatively impacting windows) while still keeping most of the benefits of #107. |
I think what nodejs extensions do is to navigate up the tree until they find the outermost package.json, we can probably do the same looking for mix.exs? In that way we can probably cover umbrella apps too. |
My understanding is this check guarantees two instances never share the same @alex88 Wouldn’t one instance per outermost I agree with reintroducing #107 somehow. Activating one ElixirLS instance per outermost |
and also the non elixir single workspaces (although that's a rare case imho), or multi workspaces where the first one isn't elixir (e.g. this happens a lot to me when I open frontend/backend and frontend is first)
you're right, my bad, I even did that part myself. I don't think that would be a problem at this point. |
Might be related to #122 |
it probably is since there might be two LS instances |
Is there any movement on this? I get two elixir-ls instances (and thus double of everything) when I run |
@cjbottaro that seems more like #122, I don't believe there's been any movement on this or #122. On #122 could you reply whether you have multiple folders in your workspace and ideally post reproduction steps with a git repo? |
Just chiming in to echo that ~6 months later, the advice above still applies. I also got this and was able to resolve by just closing open "unsaved" editor windows and restarting. In the top left of VSCode, it will tell you how many unsaved open editors you have: I used this little window to guide my hunt. After closing all unsaved tabs and restarting VSCode, I only had one ElixirLS running. |
Closing as elixir-ls instances management has been refactored. Please reopen if this is stil relevant |
Problem
ElixirLS runs two instances on my Vscode. They both do exactly the same work at their own pace, maxing out my CPU usage all the time. I can see two
beam.smp
instances in my Mac's Activity Monitor Panel, and likewise twoElixirLS
instances in Vscode's Output panel where extensions display their logs.Even when seemingly doing nothing (logs don't show any new entries), they both keep maxing out my CPU.
The logs on both start with:
The logs appear constantly identical, except the times to compile files are slightly different, indicating they are indeed two different instances doing the same things at the same time.
mix.exs
dependencies also have{:dialyzex, "~> 1.2.1", only: [:test, :dev]},
, in case that is anyhow relevant.I'm using
asdf
with the following content in my.tool-versions
:Environment
Erlang/OTP 22 [erts-10.7.2.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
Elixir 1.10.3 (compiled with Erlang/OTP 22)
The text was updated successfully, but these errors were encountered: