Hi Mark,
Got it working per your instructions.
Many thanks as now I don't need to hassle with custom RMI code or try to
get nakamura to use JMXMP which was looking quite difficult as I
couldn't find any docs on the apache.aries MBean bundle and the docs for
configuring Jetty only apply to a standalone Jetty.
So thanks again, was a great feeling to see it attach to the remote
nakamura after a day of thrashing.
John K
On 6/5/12 2:00 PM, Mark Triggs wrote:
> 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
--
John King
Applications Programmer
Learning Systems Group
Educational Technology Services
9 Dwinelle Hall - Mail
117 Dwinelle Hall - Office
University of California
Berkeley, CA 94720-2535
Phone: 510-529-5074
Email: jo...@media.berkeley.edu
_______________________________________________
oae-dev mailing list
oae-dev@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
