Hi John,
I wondered if using an SSH SOCKS proxy might do the job. Something like
this works on my local network with some local firewall rules blocking
all TCP packets but the SSH ones to my server:
On the server running the JVM, start up jstatd as normal:
$ sudo su -
# cat > jstatd.all.policy <<EOF
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
EOF
# jstatd -J-Djava.security.policy=$PWD/jstatd.all.policy
-J-Djava.rmi.server.logCalls=true
Then on the client you'll be running VisualVM from, open an SSH SOCKS
proxy:
$ ssh -N -D 1080 server.example.com
Leave that running in one window, then start VisualVM in another with
some tricky switches for using the SOCKS proxy
(nicked from http://labs.skiinfo.com/?p=77):
$ jvisualvm -J-Dnetbeans.system_socks_proxy=localhost:1080
-J-Djava.net.useSystemProxies=true
With those switches, I was able to "Add remote host" through VisualVM
and connect to the JVMs running on my server.
Cheers,
Mark
John King <jo...@media.berkeley.edu> writes:
> Folks,
>
> As part of our ongoing performance testing here at Berkeley, we want
> to use the VisualVM Java profiler to watch the app, which is running
> remotely behind a firewall, while running load tests. We have run
> into a fundamental problem doing this and I am writing to the list to
> ask if anyone has solved this particular problem in a simple, easily
> configurable manner.
>
> The problem is that we are being hindered by the nature of JMX
> (management beans) communication over RMI - the default protocol.
> The difficulty is that this protocol uses two ports, one defined by
> server configuration and a second port randomly assigned at runtime.
> Obviously the second port presents a problem in configuring a
> firewall or SSH tunnel as the second port will change when the app is
> restarted.
>
> Our Ops Engineer, Jon Felder, and I have been researching solutions to
> this problem and have found some possible approaches. - see [1] and
> [2]
>
> [1] recommends using an alternative communications protocol, JMXMP,
> which is JMX over TCP instead of RMI. As this appears to be the
> simplest solution, I am going to try this out today and will let the
> list know if it works.
> [2] involves a fair amount of custom coding based on adapting the
> example shown.
>
> A third approach involves parsing the response from the initial
> handshake for the randomly assigned port and configuring the SSH
> tunnel to use or opening that port in the firewall Jon Felder has made
> good progress on doin this but, as mentioned above, it will be
> unwieldy.
>
> Has anyone on the list solved this particular problem? Any
> suggestions as to the easiest solution will be much appreciated.
>
> [1] http://blog.markfeeney.com/2010/10/jmx-through-ssh-tunnel.html
> [2]
> https://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx
--
Mark Triggs
<m...@dishevelled.net>
_______________________________________________
oae-dev mailing list
oae-dev@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
