Pid thanks or your comments below. Any idea why it was working just fine on a windows Vista machine but not on Windows 2008 R2. One of the main differences between the two machines is that the windows server has multiple IP addresses on the same network card, could that be causing the agent to get confused as to what ip address to use for the second port.
On Thu, Dec 23, 2010 at 3:37 AM, Pid <p...@pidster.com> wrote: > On 23/12/2010 10:01, Adib wrote: > > The local process option seems to be a hit and miss on various versions > of > > windows, it was not working. Also the local process option only works if > > jconsole is running the same userid as process you want to connect to, > which > > is not the case in my tomcat setup which is running as a service. > > re: 'masks', the above is a better description. > > > I tested my setup on my Vista 64 bit laptop an it worked which narrowed > the > > problem down to something about Windows Server 2008 R2. > > > > A bit more googling led me this problem repot > > > http://tai-dev.blog.co.uk/2010/03/26/glassfish-jmx-and-windows-web-server-2008-can-play-together-with-a-few-tweaks-here-s-how-plus-bonus-jconsole-config-info-8251001/ > > > > and the fix was to add -Djava.rmi.server.hostname=127.0.0.1 to my command > > line options for the service. I have no idea why this setting fixes the > > problem but it does. > > Because when JMX looks for the connection to the second port, it uses > the hostname as part of the argument. Setting 127.0.0.1 ensures it can > find it's own ar**, if you're connecting locally. > > > Has anyone found any good documentation on how JVM instrumentation works > and > > why it is so troublesome to connect to an instrumented hotspot vm. > > Not really. I have gleaned it from various sources. > > Java 6 uses the Attach API - which enumerates JVM processes on the local > machine, and permits another Java process to attach and set system > properties, and load Java Agents. > > Tools like JConsole and VisualVM use it to display a list of processes. > > When you connect to the process, it checks to see if the JMX agent is > enabled; if not it loads the management-agent.jar from %JAVA_HOME%/lib, > which enables JMX on a 'local connector stub' - which can be read and > converted to a JMX connection. > > As you point out, the attaching process must have the same privileges as > the target process[1], but it must also be able to create a temporary > file on a filesystem which can permits user permissions (ie suitably > configured NTFS). > > > An additional complication, as described by André, is that JMX actually > needs two ports, (the other for the RMI registry), and the second port > is (usually) assigned random-ish-ly. (catalina-jmx-remote.jar fixes this.) > > > p > > >
