Eclipse Java remote debugger extremely slow over VPN

Question

I sometimes am forced to work away from my office, meaning that I need to VPN into my lab. I\'ve noticed that remote-debugging with Eclipse in this situation is horrendously slo

Answer 1

Have you tried this? http://www.gontu.org/how-you-can-debug-a-remote-java-application/

It sounds like you need to set this up in order to debug your application through VPN. This, by the way, has been answer as well in this SO posting.

I hope this helps your case. Good luck!

Answer 2

Disabling Show monitor indeed helped me.
The Bottom facing triangle is difficult to spot in debug perspective. So Just posting the image which is missing in the link.

Answer 3

From very light testing of a pretty large project (almost 100 subprojects, ping times ~200-300ms), Netbeans seems to be doing ok in comparison with Eclipse.

You can step and it takes few seconds to update and attaches in < 1 min.

It's of course annoying to not be able to use Eclipse, but it is a GUI and as such way better than plain JDB.

Answer 4

Thanks for attempting to help, guys. Luckily a colleague of mine, plagued by the same problems, did a deep dive into it. From my colleague's correspondence:

"I set up a proxy sitting between my Eclipse and my VM which printed out command codes from JDWP packets my Eclipse was sending to my VM. http://docs.oracle.com/javase/8/docs/platform/jpda/jdwp/jdwp-protocol.html page explained me what those commands meant. What I saw was: every time I stepped through the code Eclipse was sending dozens and dozens of "thread monitor" - related commands to VM. They are related to the following VM capabilities: canGetMonitorInfo, canGetCurrentContendedMonitor, canGetOwnedMonitorInfo, canGetMonitorFrameInfo"

Those capabilities are causing the insane amount of lag. He has cooked up a solution that forcably disables those capabilities, and the usability of the debugger has skyrocketed. Obviously the thread-monitoring functionality of the remote debugger no longer works, but given how unusable the remote debugging was previously, this is a great compromise.

I'll attempt to find out what exactly he did to disable the thread-monitor capabilities.