Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

On the agent side, the discovery responder automatically replies to discovery requests. Any active, registered responder in the same multicast group that is reached within the given time-to-live of the request will respond. It will automatically gather the requested information about its MBean server and send the response. The settings of the responder do not affect its automatic reply to discovery requests. In 15.2.1 Discovery Responder we will cover how its settings control passive discovery.

The discovery client can search for agents via all the connector protocols supported by Java DMK, both current and legacy. Java DMK 5.1 introduces a new DiscoveryResponse method, getServerAddresses, which is used to get the addresses of any servers registered in an MBean server as a JMXConnectorServerMBean. The getServerAddresses method can discover servers that are either instances of the JMX Remote API JMXConnectorServer, or legacy servers wrapped to appear as such. This new method ensures compatibility between the following pairs of discovery clients and servers created using versions 5.0 and 5.1 of Java DMK.

  • A Java DMK 5.0 discovery client and a Java DMK 5.1 discovery server:

    A 5.0 client can discover a 5.1 connector server, but only if it is a legacy server registered as a legacy MBean.

  • A Java DMK 5.1 discovery client and a Java DMK 5.0 discovery server:

    The method DiscoveryResponse.getObjectlist() will return a hashtable of 5.0 connector servers.

    The method DiscoveryResponse.getServerAddresses() will return an empty table.

  • A Java DMK 5.1 discovery client and a Java DMK 5.1 discovery server:

    The method DiscoveryResponse.getServerAddresses() will return a table of the addresses of all the servers that are registered as either legacy or JMX Remote API JMXConnectorServerMBean MBeans.

    The method DiscoveryResponse.getObjects() will return a vector of legacy servers that are registered as legacy MBeans.

All the above relations between versions are also true for the passive discovery monitor.

In active discovery, the discovery client controls all parameters of a search it initiates, including the response mode of the discovery responder. The discovery client determines whether responses are sent back on a different socket (unicast) or sent to the same multicast group. The default is unicast: if you want to use the multicast response mode, set the PointToPointResponse attribute to false before initiating the discovery.

15.1.2.1 Unicast Response Mode

When the PointToPointResponse boolean attribute is true, the discovery client specifies unicast mode in its discovery requests. The responder will create a datagram socket for sending the response only to the discovery client. As shown in the following diagram, each responder will send its response directly back to the discovery client. The datagram socket used by each responder is bound to its local host address; this cannot be customized.

Figure 15-1 Unicast Response Mode

Unicast response mode

15.1.2.2 Multicast Response Mode

When the PointToPointResponse boolean attribute is false, the discovery client specifies multicast mode in its requests. The discovery responder will use the existing multicast socket to send response, broadcasting it to the same multicast group as the request. As shown in the following diagram, every member of the multicast group will receive the message, but only the discovery client can make use of its contents. Multicast mode avoids having to open another socket for the response, but all of the responses will create traffic in each application's socket.

Figure 15-2 Multicast Response Mode

Multicast response mode

15.2 Passive Discovery

In passive discovery, the entity seeking knowledge about agents listens for the activation or deactivation of their discovery responders. When discovery responders are started or stopped, they send out a proprietary message that contains all discovery response information. The DiscoveryMonitor object waits to receive any of these messages from the multicast group.

A discovery monitor is often associated with a discovery client. By relying on the information from both, you can keep an up-to-date list of all agents in a given multicast group.

Figure 15-3 Passive Discovery of Discovery Responders

Diagram showing passive discovery of discovery responders

Therefore, configuring and starting the discovery responder is an important step to the overall discovery strategy of your applications.

15.2.1 Discovery Responder

The agents that are configured to be discovered must have an active DiscoveryResponder registered in their MBean server. The responder plays a role in both active and passive discovery:

  • When the start operation of a discovery responder is invoked, it sends out a multicast message indicating that it has been activated.

  • When the discovery responder is active, it automatically responds to discovery requests.

  • When the responder's MBean is unregistered or its stop operation is invoked, it sends out a multicast message to indicate that it will be deactivated.

Both types of messages are proprietary and their contents are not exposed to the user. These messages contain information about the MBean server, its delegate's information and a list of communicator MBeans, unless not requested by the discovery client.

In our example we create the discovery responder in the MBean server and then activate it. Then, we create different connector servers that will discover the agent passively, due to its active discovery responder.

Example 15-3 Creating a Discovery Responder

public class Responder {
    public static void main(String[] args) {
	      try {
	          MBeanServer myMBeanServer = 
                MBeanServerFactory.createMBeanServer();

	          echo("\nCreate and register a DiscoveryResponder MBean.");
	          ObjectName dc = 
               new ObjectName("DiscoveryExample:name=DiscoveryResponder");
          myMBeanServer.createMBean("com.sun.jdmk.discovery.DiscoveryResponder", 
                                    dc);
	          myMBeanServer.invoke(dc, "start", null, null);
	    
	          // Create an HtmlAdaptorServer on the default port.
	          [...]    
	
          // Create JMX Remote API connector servers
	    	    JMXServiceURL url;
	          JMXConnectorServer server;
	          ObjectName on;
	    
	          // rmi
	          url = new JMXServiceURL("rmi", null, 0);
	          server = 
             JMXConnectorServerFactory.newJMXConnectorServer(url, 
                                                            null, 
                                                            myMBeanServer);
	          server.start();
	          url = server.getAddress();
		    
     	    on = new ObjectName("jmx-remote:protocol=rmi");
	          myMBeanServer.registerMBean(server, on);
    	    
          // Create RMI/IIOP connector server
          [...]

          // Create JMXMP connector server
          [...]

          // stop/start the responder to send a notification
	          myMBeanServer.invoke(dc, "stop", null, null);
           Thread.sleep(100);
	          myMBeanServer.invoke(dc, "start", null, null);

          // Create wrapped legacy RMI and HTTP connector servers 
          [...]
	    
	          // Repeat for the other current and legacy connector protocols
          [...]

	          // stop/start the responder to allow a Monitor to find them
	          myMBeanServer.invoke(dc, "stop", null, null);
           Thread.sleep(100);
	          myMBeanServer.invoke(dc, "start", null, null);
           
           [...]

	          echo("All servers have been registered.");

	          echo("\n>>> Press return to exit.");
	          System.in.read();
	          System.exit(0);
	      } catch (Exception e) {
	          e.printStackTrace();
	   }
}

Previous Previous     Contents     Index     Next Next