UI proxy settings not used for remote host connections

[jdelker]

Describe the bug
The proxy configuration in VisualVM is completely ignored, when trying to establish remote jstat/jmx connections.

I tried to establish jstat/jxm connections through a constructed SOCKS-Port (ssh remote.host -D 9000) to a remote host.
Although I set the required proxy configuration in VisualVM, no traffic was tunneled through the SOCKS port at all.

Suspicion:
Proxy information present in system properties are overriding the proxy configuration in VisualVM.
(see "Additional Context" below)

To Reproduce
Steps to reproduce the behavior:

1. Configure proxy in VisualVM (localhost/9000; apply for all).
2. Open SOCKS-Tunnel to a remote host: ssh remote.host -D 9000 -v
3. Add new remote host in VisualVM.
4. After adding the host, the expected verbose output of the ssh session about usage of the SOCKS port, is not showing.
5. If output is shown, eventually set some diverting system properties as shown in "Additional Context" and repeat the procedure.

Expected behavior
VisualVM shall always honor its own proxy configuration. Any conflicting system properties shall be either ignored or unset for the VisualVM session.

VisualVM log
Sorry. I've no clue where to find that.

Desktop (please complete the following information):

• macos 11.6
• Temurin OpenJDK 17.0.1
• VisualVM 2.1.1

Additional context
Looking at the system properties in the "Overview" tab for the VisualVM process, shows the following proxy settings:

http.nonProxyHosts=local|*.local|169.254/16|*.169.254/16|localhost|*.localhost|192.168/16|*.192.168/16
http.proxyHost=other-proxy-host
http.proxyPort=3128
https.proxyHost=other-proxy-host
https.proxyPort=3128
socksNonProxyHosts=local|*.local|169.254/16|*.169.254/16|localhost|*.localhost|192.168/16|*.192.168/16

They apparently match the configured OS proxy settings, but I've no clue how they end up here as system properties.

The remote host IP used for testing was 10.10.1.130, which does not match any of the nonProxyHost definitions.

Invoking VisualVM with the CLI option -J-Djava.net.useSystemProxies=false did not show any effect to the above system properties.

Invoking VisualVM with explicit SOCKS proxy properties (-J-DsocksProxyPort=9000 -J-DsocksProxyHost=localhost) showed proper proxy usage, despite of what is configured in the UI.

[thurka]

Thanks for the report. I followed your steps to reproduce, but VisualVM works fine for me. The log file is available via VisualVM -> About -> Logfile

[jdelker]

Thanks for the report. I followed your steps to reproduce, but VisualVM works fine for me. The log file is available via VisualVM -> About -> Logfile

That is VisualVM using the configured proxy in the UI, although there are other proxy settings in the system properties?
Did you verify, that the remote connection has been actually established through the UI configured proxy and not worked through other ways?

If all is "yes", what other possible reasons are there, that could prevent VisualVM from using the UI configured proxy?

[jdelker]

Logfile from VisualVM:
logfile.txt

[jdelker]

Apart from the remote host connection, I can also see that http(s) traffic (e.g. from the plugin dialog) passes the "other-proxy-host" and not the configured proxy in VisualVM.

[thurka]

Thanks for the report. I followed your steps to reproduce, but VisualVM works fine for me. The log file is available via VisualVM -> About -> Logfile

That is VisualVM using the configured proxy in the UI, although there are other proxy settings in the system properties?

No, system properties match the UI.

Did you verify, that the remote connection has been actually established through the UI configured proxy and not worked through other ways?

Yes.

[thurka]

Please run VisualVM from Terminal and add the following: -J-Dorg.netbeans.core.network.level=100. VisualVM log file should have more info about your proxy setting. Maybe this help to explain what is going on.

[jdelker]

That is VisualVM using the configured proxy in the UI, although there are other proxy settings in the system properties?

No, system properties match the UI.

Uh! If your system properties match the UI settings, you can't tell which setting VisualVM is actually following.
Please see step 5) in the reproduction notes. (I edited that, to be more precise)

[jdelker]

Please run VisualVM from Terminal and add the following: -J-Dorg.netbeans.core.network.level=100. VisualVM log file should have more info about your proxy setting. Maybe this help to explain what is going on.

Unfortunately, it hasn't. See attached logfile_level100.txt:
logfile_level100.txt

What I did:

1. Started VisualVM from CLI with /Applications/VisualVM.app/Contents/MacOS/visualvm -J-Dorg.netbeans.core.network.level=100
2. Opened Local/VisualVM process, to inspect effective system properties (proxy settings). They show

   http.nonProxyHosts=local|*.local|169.254/16|*.169.254/16|localhost|*.localhost|192.168/16|*.192.168/16
   http.proxyHost=localhost
   http.proxyPort=3128
   https.proxyHost=localhost
   https.proxyPort=3128
   socksNonProxyHosts=local|*.local|169.254/16|*.169.254/16|localhost|*.localhost|192.168/16|*.192.168/16
   

   which matches my general OS system proxy configuration for HTTP(S).
3. Opened VisualVM>Preferences>Network to check the configured UI proxy settings.
   They point to localhost/9000 for all protocols (including socks) to utilize the established SSH-Socks-Tunnel.
   (Expected behavior: VisualVM uses this settings over any system properties to establish connections)
4. Performed "Add Remote Host" on Remote Folder to add a new remote host.
5. Host is added, but VisualVM does not connect to it via the UI configured socks proxy. Instead I see direct connection attempts to the remote host, when snooping the default network interface.
   (Conclusion: VisualVM does not use the UI configured proxy, but the system properties - where no socks proxy is configured in this case. Proof: HTTP requests, e.g. from Plugin-Download, hit the proxy on localhost:3128, while they actually should use localhost:9000 - and fail of course.)

The attached logfile documents this process, but unfortunately doesn't show any network communication.

Any other hints?

[thurka]

That is VisualVM using the configured proxy in the UI, although there are other proxy settings in the system properties?

No, system properties match the UI.

Uh! If your system properties match the UI settings, you can't tell which setting VisualVM is actually following.

I can, since system properties are updated when I change the settings in the UI.

[thurka]

Any other hints?

Can you try different JDK? What about JDK 8? Use --jdkhome on command line to specify path to JDK home directory, and use About dialog to verify that you are running right JDK. You can also try non-default userdir (--userdir /tmp/visualvm_test). Always add -J-Dorg.netbeans.core.network.level=100 so we can get more details (hopefully) and attach the log file. You can also add -J-Dnetbeans.logger.console=true -J-ea - to enable assertions and to log directly to terminal window.

[thurka]

Good news! I am able to reproduce it. It looks like this is Big Sur only issue.

[jdelker]

That is VisualVM using the configured proxy in the UI, although there are other proxy settings in the system properties?

No, system properties match the UI.

Uh! If your system properties match the UI settings, you can't tell which setting VisualVM is actually following.

I can, since system properties are updated when I change the settings in the UI.

Oh, ok! Let me check if, I understand this correctly:
If I change the proxy settings in VisualVM-UI, this should reflect on the system properties, seen in the Overview tab on the VisualVM process?
In that case, this is probably the problem, because it doesn't do that here.

[thurka]

Problem is in netbeans platform. It uses older version of JNA, which does not work well with Big Sur.

java.lang.UnsatisfiedLinkError: Unable to load library 'CoreServices':
dlopen(libCoreServices.dylib, 9): image not found
dlopen(libCoreServices.dylib, 9): image not found
Native library (darwin/libCoreServices.dylib) not found in resource path (/Users/thurka/Projects/visualvm_211/platform/lib/boot.jar:/Users/thurka/Projects/visualvm_211/platform/lib/org-openide-modules.jar:/Users/thurka/Projects/visualvm_211/platform/lib/org-openide-util-lookup.jar:/Users/thurka/Projects/visualvm_211/platform/lib/org-openide-util-ui.jar:/Users/thurka/Projects/visualvm_211/platform/lib/org-openide-util.jar)
	at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:302)
	at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:455)
	at com.sun.jna.Library$Handler.<init>(Library.java:192)
	at com.sun.jna.Native.load(Native.java:596)
	at com.sun.jna.Native.load(Native.java:570)
	at org.netbeans.core.network.proxy.mac.MacNetworkProxyLibrary.<clinit>(MacNetworkProxyLibrary.java:30)
	at org.netbeans.core.network.proxy.mac.MacNetworkProxy.<clinit>(MacNetworkProxy.java:37)
	at org.netbeans.core.network.proxy.NetworkProxyReloader.getNetworkProxyResolver(NetworkProxyReloader.java:204)
	at org.netbeans.core.network.proxy.NetworkProxyReloader.<clinit>(NetworkProxyReloader.java:56)
	at org.netbeans.core.network.proxy.NbProxySelector.<init>(NbProxySelector.java:58)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at java.base/java.lang.Class.newInstance(Class.java:584)
	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:41)
[catch] at org.openide.util.lookup.MetaInfServicesLookup$Item.getInstance(MetaInfServicesLookup.java:489)
	at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:397)
	at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:281)
	at org.netbeans.core.CoreBridgeImpl.doRegisterPropertyEditors(CoreBridgeImpl.java:185)
	at org.netbeans.core.CoreBridgeImpl.registerPropertyEditors(CoreBridgeImpl.java:148)
	at org.netbeans.core.startup.Main.start(Main.java:285)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
	at java.base/java.lang.Thread.run(Thread.java:829)