Details

    • Issuezilla Id:
      168

      Description

      At this time VisualVM (as JConsole) because of JMX&RMI issues are
      is not working behind SSH.

      See
      http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html#gdfvv
      http://java.sun.com/javase/6/docs/technotes/guides/management/faq.html#rmi1

      Most production machines are nowadays only accessible thru a SSH layer (because
      beeing in protected areas in white rooms). Not having a SSH friendly solution
      means, not beeing able to supervision most environment.

      This is blocking because there is no way at this time to workaround the
      situation, thus preventing anybody to use VisualVM on such environment.

        Activity

        Hide
        scoopex added a comment -

        Still waiting for this feature.

        There is a workaround (see http://gabenell.blogspot.de/2010/04/connecting-to-jmx-on-tomcat-6-through.html) - but with this settings it is not possible to use the VisualGC plugin (which needs jstatd connectivity).

        Using VisualVM on remotehosts behind a firewall ist still a real pain!

        Show
        scoopex added a comment - Still waiting for this feature. There is a workaround (see http://gabenell.blogspot.de/2010/04/connecting-to-jmx-on-tomcat-6-through.html ) - but with this settings it is not possible to use the VisualGC plugin (which needs jstatd connectivity). Using VisualVM on remotehosts behind a firewall ist still a real pain!
        Hide
        scoopex added a comment - - edited

        From my point of view it would be a cool thing to have the possibility to run visalvm divided in two processes:

        1.) The backend

        • runs at serverside
        • connect to local procces ids via vm.attach()
          (for security reasons this would be a nice thing in production environments - only users with acces to that
          process/user can connect - no extra jmx account management)
        • provides access to all jvms(pids) which run on this system
        • analysis at serverside

        2.) The frontend

        • runs on the developer workstation
        • displays data and interacts with the user
        • opens a ssh channel, uploads the backend to /tmp/visalvm-<randomkey>, executes the backend, communicates
          over stdin/stdout with the server process
          => Support for SSH Keys would be good
          => Support for jumphosts would be great (workstation --SSH--> jumphost ---SSH--> production machine)

        It seems that only via vm.attach(<process-id>) the full features of visualvm are available....is that correct?

        Show
        scoopex added a comment - - edited From my point of view it would be a cool thing to have the possibility to run visalvm divided in two processes: 1.) The backend runs at serverside connect to local procces ids via vm.attach() (for security reasons this would be a nice thing in production environments - only users with acces to that process/user can connect - no extra jmx account management) provides access to all jvms(pids) which run on this system analysis at serverside 2.) The frontend runs on the developer workstation displays data and interacts with the user opens a ssh channel, uploads the backend to /tmp/visalvm-<randomkey>, executes the backend, communicates over stdin/stdout with the server process => Support for SSH Keys would be good => Support for jumphosts would be great (workstation -- SSH -- > jumphost ---SSH --> production machine) It seems that only via vm.attach(<process-id>) the full features of visualvm are available....is that correct?
        Hide
        scoopex added a comment -

        I also experienced this problem. Typically i use the following commandline to tunnel to a remote server (firewalls typically do not permit access to hosting areas):

        ssh -L 10001:127.0.0.1:10001 my-server.hosting.org

        This command tunnels port 10001 of the remote system to my local system (127.0.0.1/localhost) port 10001.

        Visualvm rejects to open a jmx connection to port 10001 with a notification that "...localhost is already monitored..."
        It seems that the logic for detecting duplicate connections should improved.

        You can workaround this problem using a socks tunnel:
        (but this is not available for every ssh client)

        1.) Connect to server
        ssh -D 10002 my-server.hosting.org
        2.) Execute Visualvm on your workstation
        ./visualvm -J-Dnetbeans.system_socks_proxy=localhost:10002 -J-Djava.net.useSystemProxies=true

        It also seems that some features (i.e. tracing) are nit available using jmx connections over network.
        A great advantage would be a tiny remote server daemon which utilizes the java vmattach api (access via process id)
        and exposes access to all jvms over network. A new connection type in visualvm opens the connection to this daemon.
        running on this host. This connection can be tunnelled via SSH or exposed over a single port (then we need authentication and encryption) - probably we do not need a new communication protocol and use the existing.....

        I think comfortable remote access is essential for making visualvm to be the most popular java-profiling-tool )

        Show
        scoopex added a comment - I also experienced this problem. Typically i use the following commandline to tunnel to a remote server (firewalls typically do not permit access to hosting areas): ssh -L 10001:127.0.0.1:10001 my-server.hosting.org This command tunnels port 10001 of the remote system to my local system (127.0.0.1/localhost) port 10001. Visualvm rejects to open a jmx connection to port 10001 with a notification that "...localhost is already monitored..." It seems that the logic for detecting duplicate connections should improved. You can workaround this problem using a socks tunnel: (but this is not available for every ssh client) 1.) Connect to server ssh -D 10002 my-server.hosting.org 2.) Execute Visualvm on your workstation ./visualvm -J-Dnetbeans.system_socks_proxy=localhost:10002 -J-Djava.net.useSystemProxies=true It also seems that some features (i.e. tracing) are nit available using jmx connections over network. A great advantage would be a tiny remote server daemon which utilizes the java vmattach api (access via process id) and exposes access to all jvms over network. A new connection type in visualvm opens the connection to this daemon. running on this host. This connection can be tunnelled via SSH or exposed over a single port (then we need authentication and encryption) - probably we do not need a new communication protocol and use the existing..... I think comfortable remote access is essential for making visualvm to be the most popular java-profiling-tool )
        Hide
        jsedlacek added a comment -

        Could you please be more specific on what exactly doesn't work for you?
        Also, could you please describe how would you like the VisualVM to support the
        SSH tunelling? Thanks.

        Show
        jsedlacek added a comment - Could you please be more specific on what exactly doesn't work for you? Also, could you please describe how would you like the VisualVM to support the SSH tunelling? Thanks.

          People

          • Assignee:
            visualvm-issues
            Reporter:
            bjb
          • Votes:
            5 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: