score:3

Accepted answer

Well I am answering myself after a long time; in my specific case, the solution was to put eclipse JVM in listening mode:

Connection Type: "Standard (Socket Listen)"

and reverse the direction of the tunnel:

ssh -L 8001:localhost:8001 user@work   (run on server (S), "localhost" is W)
ssh -R 8001:localhost:8001 user@work   (run at home (H), "localhost" is W)

Some explanation: as in the question, my situation was:

  H  -------------------> S     not working  ( ssh -L 8001:S:8001 user@S  from H)
  H           W  -------> S     working      ( ssh -L 8001:S:8001 user@S  from W)
 home        work      server

While reversing like this:

  H  <------- W           S     ssh -R 8001:localhost:8001 user@W  (from H)
  H           W  <------- S     ssh -L 8001:localhost:8001 user@W  (from S)
 home        work      server

did the trick. In other words, whatever is written on S:8001, is forwarded to W:8001, and whatever in turn is written to W:8001, is forwarded to H:8001, where my eclipse JVM is listening.

The tomcat JVM on S should be started with server=n, with arguments:

-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=8001

score:3

Can you please give the exact parameters of the -Xrunjdwp parameter?

Also do you have tried different methods for debugging (server=y/n, suspend=y/n)?

Perhaps inversing the connection (let the tomcat connect to the debugger instead of letting the debugger connect to tomcat) may help.

score:8

Assuming the remote Tomcat instance has been started with something like -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n, try this command:

ssh -L 8000:0.0.0.0:8000 user@mycompany.com -N

On my Mac, I tried out ssh -L 10701:localhost:10700 user@localhost -N locally, where a Tomcat instance was started with -Xrunjdwp:transport=dt_socket,server=y,address=10700,suspend=n, and attempting to attach on port 10701 within Eclipse, I kept seeing "Failed to connect to remote VM com.sun.jdi.connect.spi.ClosedConnectionException". By changing the tunnel command to ssh -L 10701:0.0.0.0:10700 user@localhost -N, Eclipse was able to attach.

score:10

This article suggests that the default port on which the remote Java virtual machine (JVM) is listening in debugging mode is 1044. You should tunnel the port on which the remote JVM is running as well.

More generally, you could run wireshark/tcpdump to see to which port connection attempts are made when starting the debugger.

EDIT:

A few more things I would try:

  • check on the remote host (e.g. with ps auxwww if it's Linux) with which arguments (look for what comes behind -Xrunjdwp or with lsof -p PID_OF_JVM_TO_BE_DEBUGGED on which TCP port it listens (look for lines with TCP and LISTEN in the lsof output)
  • make sure that the JVM on the remote host listens on the lo interface, not the network interface (that's what you specify with the localhost in the -L option to ssh).
  • Does starting the debugger by hand on the machine where you start eclipse with jdb -attach localhost:8000 work ? (you could also try this on the remote host to ensure the debugger is running on the port 8000)
  • make sure that eclipse tries to connect to localhost (when not specifying a bind address before the first 8000 with the -L option ssh listens on the lo interface)

score:10

I often had this problem when doing remote debugging. I do not know the exact reason for this problem, but I used the below solution and maybe it works for you, too:

instead of

ssh -L 8000:localhost:8000 user@remotehost

is used

ssh -L 8000:remotehost:8000 user@remotehost

for creating the SSH tunnel (note the remotehost instead of localhost between the port numbers in the second example). Instead of the remote host's name, you can also use the normal IP address of the remote host (not the loopback address 127.0.0.1, but the true local network IP address).

Hope it helps and good luck!


Related Query

More Query from same tag