Environment: I was using VisualVM IntelliJ plugin to investigate a memory leak in a standard OpenJDK Java 8 service I have running locally, and I believe I solved the application bug.
Problem: However, during my local validation effort, as I left the service to run for a long period of time, it was discovered that whenever I connect to my company's VPN while leaving the monitoring running, it can be observed within the graph of heap size over time that the period between Garbage Collector triggers is greatly lengthened while my laptop is connected to the VPN. It is as if VisualVM decreased some polling interval that normally causes the application to allocate memory more quickly. Then, when I switch the VPN off, the opposite occurs and it goes back to the original rate of allocation/GC triggers it was at before. Why would this occur? There must be some relation with JMX and network that I am missing and can't seem to find any explanation for thus far.
I have tried connecting and disconnecting the VPN a few times, and noticed this same pattern of behavior each time. I would expect it not act differently depending on the local network, when there is no discernable trait of the network that has changed that should affect the rate of memory allocation due to VisualVM polling considering the fact that local connections in VisualVM use 127.0.0.1... but I must be missing something if this is the case. It should be noted that my LAN network does support IPv6 so there is both an IPv6 and an IPv4 address on the LAN before connecting to the VPN. But I have no evidence of which one VisualVM prefers at any given time, other than what is visible in the properties of the "Local" connection, which only shows 127.0.0.1.
Another thing to note is that beginning at the time when the first connection to the VPN was made, the memory and CPU Sampling options within the Sampler tab of VisualVM stopped updating and refused to work despite a few different attempts BUT the Monitor tab continues to update, even after I returned the network to the original settings by disabling the VPN.
Closing the connection in VisualVM and re-opening it for the entire application causes everything to be blanked out while on the VPN, as if it is unable to connect. However if I stop the VPN and re-open the connection to the application, everything works as expected. What is happening that could cause this under the hood of JMX? Similar issues have been observed with JConsole/JMC as well, as I explain in this completely separate topic from over a year ago, however in that case I never attempted to stay connected and see if it continued to update after connecting to the VPN - which apparently the Monitor tab is capable of in the case of VisualVM... but how is this possible?
Given the additional facts of this VPN-LAN config issue, which seems highly suspicious, my initial question should be amended to also ask "how does VisualVM stay connected on the Monitor tab while on the VPN when seemingly it shouldn't due to this VPN configuration?" Is a separate connection/protocol used to obtain that information? But then why doesn't the Monitor tab work when I open the connection to the app while already connected to the VPN, when at the same time it continues to work when I turn on the VPN after first opening the connection? This seems to be inconsistent behavior.