StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6985565
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2011-08-08T16:48:51.440
FavoriteCount
0
LastActivityDate
2012-07-27T01:10:14.183
LastEditDate
2012-07-27T01:10:14.183
LastEditorUserId
62130
OwnerUserId
884463
ParentId
516142
PostTypeId
2
Score
86
ViewCount
0
LastEditorDisplayName
text
Body
AFAIK, Here are the possibilites for connecting a JMX client process (a management application like jconsole, jmxterm, mc4j, jvmstat, jmxmonitor, jps, ...) to a JMX server process (the agent). The protocol connecting JMX client and JMX server is assumed to be 'Java RMI' (aka 'RMI-JRMP'). This should be the default. One can configure <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/jmx/overview/connectors.html#wp5529" rel="noreferrer">other protocols</a>, in particular 'RMI-IIOP' and 'JMXMP'. Special protocols are possible: the <a href="http://mx4j.sourceforge.net/" rel="noreferrer">MX4J</a> project for example additionally provides SOAP/HTTP and various serialization protocols over HTTP. Refer to <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/management/agent.html" rel="noreferrer">Sun/Oracle docs</a> for details on configuration. Also have a look at the file <code>jre/lib/management/management.properties</code> in your JDK distribution. So, the possibilities: Case 0: The JVM is started without any particular configuration Before Java 6: The JVM does not behave as a JMX server. Any program that is run inside the JVM may access the JVM's <a href="http://docs.oracle.com/javase/6/docs/api/javax/management/MBeanServer.html" rel="noreferrer">MBeanServer</a> programmatically and use it to do interesting data exchanges between threads or to do JVM monitoring, but no management from outside the JVM process is possible. Since Java 6: Even if not explicitely configured, one can access JMX functionality of the JVM locally (from the same machine) as described in "Case 1". Case 1: The JVM is started with <code>-Dcom.sun.management.jmxremote</code> The JVM is configured to work as a local (same-machine-only) JMX server. In this case (and in principle only for Sun/Oracle JVMs) a JMX client can connect to the JMX server through memory-mapped files found in <code>/tmp/hsperfdata_[user]</code>. This is alluded to in the Sun documentation and called "local monitoring" (and also the <a href="http://docs.oracle.com/javase/6/docs/jdk/api/attach/spec/index.html" rel="noreferrer">Attach API</a>). It does not work on FAT filesystems as permissions cannot be set correctly there. See <a href="https://blogs.oracle.com/lmalventosa/entry/jconsole_local_process_list_on" rel="noreferrer">this blog entry</a>. Sun recommends running <code>jconsole</code> on a machine separate from the JMX server as <code>jconsole</code> apparently is a resource hog, so this "local monitoring" thing is not necessarily a good idea. Local monitoring is, however, rather secure, only being usable locally and being easily controlled through filesystem permissions. Case 2: The JMX server is started with <code>-Dcom.sun.management.jmxremote.port=[rmiregistryport]</code> The JVM is configured to work as a JMX server listening on several TCP ports. The port specified on the command line will be allocated by the JVM and an RMI registry will be available there. The registry advertises a connector named 'jmxrmi'. It points to a second, randomly allocated TCP port (an 'ephemeral' port) on which the JMX RMI server listens and through which actual data exchange takes place. Local as described in 'Case 1' is always enabled in 'Case 2'. The JMX server listens on all interfaces by default, so you can connect to it (and control it) by locally connecting to 127.0.0.1:[rmiregistryport] as well by remotely connecting to [any outside IP address]:[some port] remotely. This implies that you have to look at the security implications. You can make the JVM listen on 127.0.0.1:[rmiregistryport] only by setting <code>-Dcom.sun.management.jmxremote.local.only=true</code>. It is rather unfortunate that one cannot specify where the ephemeral port will be allocated - it is always chosen randomly at startup. This may well mean that your firewall needs to become the swiss cheese of the damned! However, there are <a href="http://olegz.wordpress.com/2009/03/23/jmx-connectivity-through-the-firewall/" rel="noreferrer">workarounds</a>. In particular, Apache Tomcat sets the ephemeral JMX RMI server port via its <a href="http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#Additional_Implementations" rel="noreferrer">JMX Remote Lifecycle Listener</a>. The code to perform this little magic can be found at <a href="http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina-jmx-remote/7.0.14/org/apache/catalina/mbeans/JmxRemoteLifecycleListener.java/" rel="noreferrer">org.apache.catalina.mbeans.JmxRemoteLifecycleListener</a>. If you use this method, you might as well make sure that: <ol> <li>The JMX client has to authenticate to the JMX server</li> <li>The TCP exchange between the client and server is encrypted using SSL</li> </ol> How that is done is described in <a href="http://docs.oracle.com/javase/6/docs/technotes/guides/management/agent.html" rel="noreferrer">the Sun/Oracle documentation</a> Other approaches You can do interesting permutations to avoid having to use the RMI protocol. In particular, you could add a servlet engine (like Jetty) to your process. Then add servlets that translate some HTTP-based exchange internally into direct accesses to the JVM's <code>MBeanServer</code>. You would then be in 'case 0' but still have management capabilities, possibly through an HTML-based interface. The <a href="http://docs.oracle.com/javase/1.5.0/docs/guide/management/SNMP.html" rel="noreferrer">JBoss JMX Console</a> is an example of this. More off-topic, you could use SNMP directly (something I haven't tried) according to <a href="http://docs.oracle.com/javase/1.5.0/docs/guide/management/SNMP.html" rel="noreferrer">this document</a>. Show and Tell Time And now it's time for some code to illustrate a JXM exchange. We take inspiration from <a href="http://docs.oracle.com/javase/tutorial/rmi/client.html" rel="noreferrer">a Sunoracle tutorial</a>. This runs on Unix. We use a JVM that is configured as a JMX server using: <code>-Dcom.sun.management.jmxremote.port=9001</code> We use <code>lsof</code> to check what TCP ports it is holding open: <code>lsof -p <processid> -n | grep TCP</code> One should see something like this, the registry port and the ephemeral port: <pre><code>java 1068 user 127u IPv6 125614246 TCP *:36828 (LISTEN) java 1068 user 130u IPv6 125614248 TCP *:9001 (LISTEN) </code></pre> We use <code>tcpdump</code> to inspect the packet exchange between JMX client and JMX server: <code>tcpdump -l -XX port 36828 or port 9001</code> We set up a file <code>.java.policy</code> in the home directory to allow the client to actually connect remotely: <pre><code>grant { permission java.net.SocketPermission "<JMX server IP address>:1024-65535", "connect,resolve"; }; </code></pre> And then we can run this and see what happens: <pre><code>package rmi; import java.rmi.registry.LocateRegistry; import java.rmi.registry.Registry; import javax.management.remote.rmi.RMIConnection; import javax.management.remote.rmi.RMIServer; public class Rmi { public static void main(String args[]) throws Exception { // We need a Security Manager (not necessarily an RMISecurityManager) if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); } // // Define a registry (this is just about building a local data structure) // final int comSunManagementJmxRemotePort = 9001; Registry registry = LocateRegistry.getRegistry("<JMX server IP address>", comSunManagementJmxRemotePort); // // List registry entries. The client connects (using TCP) to the server on the // 'com.sun.management.jmxremote.port' and queries data to fill the local registry structure. // Among others, a definition for 'jmxrmi' is obtained. // System.out.print("Press enter to list registry entries"); System.in.read(); String[] names = registry.list(); for (String name : names) { System.out.println("In the registry: " + name); } // // 'Looking up' the entry registered under 'jmxrmi' involves opening and tearing down // a TCP connection to the 'com.sun.management.jmxremote.port', as well as a TCP // connection to an ephemeral secondary port chosen at server startup. // The actual object locally obtained is a "javax.management.remote.rmi.RMIServerImpl_Stub" // indicating where the ephemeral port is. // "RMIServerImpl_Stub[UnicastRef [liveRef: [endpoint:[$IP:$EPHEMERAL_PORT](remote),objID:[-62fb4c1c:131a8c709f4:-7fff, -3335792051140327600]]]]" // System.out.print("Press enter to get the 'jmxrmi' stub"); System.in.read(); RMIServer jmxrmiServer = (RMIServer)registry.lookup("jmxrmi"); System.out.println(jmxrmiServer.toString()); // // Now get a "RMI Connection" to the remote. This involves setting up and tearing // down a TCP connection to the ephemeral port. // System.out.print("Press enter to get the 'RMIConnection'"); System.in.read(); RMIConnection rcon = jmxrmiServer.newClient(null); // // Ask away. This involves setting up and tearing // down a TCP connection to the ephemeral port. // System.out.print("Press enter to get the 'domains'"); System.in.read(); for (String domain : rcon.getDomains(null)) { System.out.println("Domain: " + domain); } // // Ok, that will do. For serious applications, we better use the higher-level JMX classes // } } </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODoes Java 6 open a default port for JMX remote connections?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USEsko Luontola
UserOwnerUserId
1. USDavid Tonhofer
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COSmall correction - jps and jvmstat do not use JMX at all.
 singulars
 PostPostId
 PO
 UserUserId
 USTomas Hurka
2. COI also had to add `-Djava.rmi.server.hostname=127.0.0.1` otherwise the default hostname was 127.0.1.1.
 singulars
 PostPostId
 PO
 UserUserId
 USJan Kronquist

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.