How do I control the ports in use by SonarLint?

TrevorDearham · October 25, 2021, 10:21am

Each instances uses a lot of ports (see image below for the list in one instance), which end up conflicting with ports that I normally use for development. I normally have more than one instance of vscode open, which then mean more instances of SonarLint. How do I control the ports in use by SonarLint?

vscode-instider 1.62.0 (Commit bcb9df5afa52c5b713f62e86dcac2c5050504b5f) on Windows 10
SonarLint 3.0.0
Not using connected mode

duncanp · November 30, 2021, 6:06pm

@TrevorDearham apologies for the delay in replying.

Which IDE are you using?

As far as I’m aware, SonarLint only listens on one port. The range is fixed, and each new instance will use the first free port.

Kirill_Knize · December 1, 2021, 12:07pm

Hello @TrevorDearham,
One instance of SonarLint uses first available port in range 64120-64130 if there is at least one available. In your case I believe it’s 64123. Here is the link to the class that responsible for server.
Also you should see in logs exactly what port has been taken by current instance of SonarLint. Here you can see how to setup logs output in VSCode.
It will be the message “Started security hotspot handler on port $portNumber” if at least one port in range is available or the error message “Unable to start security hotspot handler” if whole range is taken by another apps. You can find logging code in the same class I referred above. So I don’t think list of ports in range 3297-3362 on screenshot you provided is taken by SonarLint.
I hope it helps and I’m ready to answer other questions you have.

Kirill_Knize · December 2, 2021, 12:30pm

Hello again, @TrevorDearham
The problem can be in language server that also running on separate port. If you restarted/turned off VSCode dozens of times and during restart language server didn’t properly stoped - you can get such picture.
Did you experienced something close to situation I described?

TrevorDearham · December 2, 2021, 2:12pm

Thank you @duncanp and @Kirill_Knize for your responses.

@duncanp I’m using vscode-insider. Yes each instance only listens on one port, but opens around 65 ports, which appear to be back to itself. I’m more concerned about the 65 ports that are consuming ports I use, e.g. 3306 in the above screenshot is the default MySQL port. Also I have more than one window of vscode open and so have more than one instance of the extension open, so the number of ports being consume quickly multiplies.

@Kirill_Knize The above image is from Process Explorer looking just at the process java -jar sonarlint-ls.jar ... and so they are a reflection of all the ports being consumed by that process alone both in listening and any internal and external network connections. I see the same number of ports being consumed for each and every instance of this process all the time (first load of vscode, reload after update, etc.). These connections are permanently open, rather than changing over time.

Would you be able to open a tool that tracks network connections to check this? netstat will show them as java.exe, so the following Powershell will show you netstat -abn | select-string -Context 2 java.exe. Process Explorer makes it much more obvious that the above process is the cause and is powerful in many other ways, so I would recommend taking a look at it.

I’m now using SonarLint 3.1.0 with the same result.

JBL_SonarSource · December 3, 2021, 11:54am

Hello, as far as I can tell, there is no reason (in the source code) for the SonarLint Language Server to open random TCP sockets to itself like this.

I am watching in Process Explorer an instance of the SonarLint Language Server running from the current (stable) VSCode and I see only 3 ports in use:

one for the communication between VSCode and the LS (expected)
one for the communication between the Java and Node sides of the JS/TS analyzer (expected if you analyze JS or TS code)
one in LISTENING state for the Security Hotspot handler

Which JRE are you using to run the Language Server? Could it be running with an agent that squats those ports?

Could you please try to capture a thread dump of the offending process and attach it here? We might notice stuff that have nothing to do there

TrevorDearham · December 3, 2021, 12:13pm

Thank you @JBL_SonarSource for looking into it and your help.

I’m using the latest Eclipse Temurin 11 as my JRE (jdk-11.0.13+8). I don’t recall changing any settings, so I think it is the default.

I’ve attached a thread dump.
sonarlint-ls.log (49.2 KB)

JBL_SonarSource · December 3, 2021, 2:16pm

Hm, the plot thickens . New round of questions then !

Are the ports correctly released when you close VSCode?
Does the process open them from the beginning when you start VSCode? If not, do you notice any trigger?
Could you please set sonarlint.output.showVerboseLogs and sonarlint.output.showAnalyzerLogs to true in your user settings, restart VSCode, and attach here an extract of the SonarLint output (Ctrl+Shift+U, “SonarLint: Show SonarLint Output”) from the start to when the accumulation of ports begins?
Are you using connected mode? If so, do you have any custom plugins on the server?

[EDIT]
As crazy as it is, I just reproduced the behavior you report with the latest Temurin 11, it seems related to the Apache HTTP Client library that we use - it looks like it squats 2 ports per worker thread, in theory more at the end of the “free” ports range (around 60000+), but I guess that if you often stop/start, it can eat up also in the low range.

I did not observe this behavior with the latest Temurin 17, so if you can, I would suggest that you use it instead of 11, as a workaround while we’re investigating

JBL_SonarSource · December 3, 2021, 2:46pm

My guess is that the implementation of java.nio.channels.Selector changed between OpenJDK 11 and 17: 11 uses a socket-based implementation, whereas 17 uses a new implementation.

See e.g:

The stack trace from a worker thread in your Temurin 11 dump:

"httpclient-dispatch-1" #25 daemon prio=5 os_prio=0 cpu=93.75ms elapsed=536.80s tid=0x00000152462b3800 nid=0x3084 runnable  [0x0000000e457fe000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(java.base@11.0.13/Native Method)
	at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(java.base@11.0.13/WindowsSelectorImpl.java:357)
	at sun.nio.ch.WindowsSelectorImpl.doSelect(java.base@11.0.13/WindowsSelectorImpl.java:182)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.13/SelectorImpl.java:124)
	- locked <0x00000004010016f0> (a sun.nio.ch.Util$2)
	- locked <0x0000000401001588> (a sun.nio.ch.WindowsSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@11.0.13/SelectorImpl.java:136)
	at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:113)
	at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
	at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
	at java.lang.Thread.run(java.base@11.0.13/Thread.java:829)

The one from the same worker thread in my Temurin 17 dump:

"httpclient-dispatch-1" #24 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=510.46s tid=0x000001b4c4ca3f70 nid=0x3f78 runnable  [0x000000978d3ff000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.WEPoll.wait(java.base@17.0.1/Native Method)
        at sun.nio.ch.WEPollSelectorImpl.doSelect(java.base@17.0.1/WEPollSelectorImpl.java:111)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@17.0.1/SelectorImpl.java:129)
        - locked <0x00000007176575c0> (a sun.nio.ch.Util$2)
        - locked <0x00000007176574b8> (a sun.nio.ch.WEPollSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(java.base@17.0.1/SelectorImpl.java:141)
        at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:113)
        at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
        at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
        at java.lang.Thread.run(java.base@17.0.1/Thread.java:833)

TrevorDearham · December 3, 2021, 2:57pm

Thank you @JBL_SonarSource for your continued help on this.

Yes
From the start or at least by the time I can view it in Process Explorer, all the ports are open and stay open. All 65 established ports are open before the listening port is open.
Depending on want the content of the folder is, sometimes the log is short and sometimes it is longer. Still the same number of ports are consumed. I’ve attached one where the content didn’t appear to trigger plugins and one where it did.
No I’m not using connected mode

Thank you. As you said, moving to Temurin 17 resulted in 1 listening port and 1 established port, so it seems to be something with Temurin 11. Given that I can specify which JDK SonarLint uses, I don’t see any issue with using Temurin 17 for SonarLint.

The port ranges it selects on my PC are generally in the low range (2000-6000), which is why it generally end up colliding with ports I want, although with multiple restarts to test this, I did see it set a port range from 11500.
Sonarlint Output 1.log (1.4 KB)
Sonarlint Output 2.log (9.8 KB)

system · December 10, 2021, 2:58pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.