19.3. Monitoring Identifiers

19.3.1. Endpoint Monitoring Identifiers

19.3.1.1. Default Endpoint Monitoring Identifiers

Each endpoint is given a unique monitoring identifier (also call "root name"). That identifier is made up of (in order):

  • The context path (if it is available).
  • The local part of the service name.
  • The local part of the port name.

For example, suppose one creates a web application with a context path of /AddNumbersService and a Metro web service is deployed under that context path with an AddNumbersService service name and a AddNumbersPort port name. Then the identifier will be:

/AddNumbersService-AddNumbersService-AddNumbersPort

When deploying in GlassFish an INFO log message is output to GlassFish's server.log file when the monitoring root is created. In this example the message would be:

Metro monitoring rootname successfully set to: amx:pp=/mon/server-mon[server],type=WSEndpoint,name=/AddNumbersService-AddNumbersService-AddNumbersPort

The name part is the identifier. The amx:pp=... part reflects that this Metro endpoint is federated under GlassFish's AMX tree. Note: when deploying in non-GlassFish containers then Metro monitoring will be under a top-level node: com.sun.metro.

19.3.1.2. User-assigned Endpoint Monitoring Identifiers

It is possible to give user-assigned identifiers to monitoring endpoints. Include an id attribute in the ManagedService policy assertion. For example:

          <sunman:ManagedService
              xmlns:sunman="http://java.sun.com/xml/ns/metro/management"
              management="false"
              monitoring="true"
              id="ExampleService"
          >
          </sunman:ManagedService>

In this case, the INFO log will say:

Metro monitoring rootname successfully set to: amx:pp=/mon/server-mon[server],type=WSEndpoint,name=ExampleService

19.3.2. Client monitoring identifiers

19.3.2.1. Default Client Monitoring Identifiers

Each client stub is given a unique monitoring identifier. That identifier is the endpoint address of the service it will communicate with. For example, for a client of the AddNumbersService above the identifier, as shown in GlassFish's log, will be:

Metro monitoring rootname successfully set to: amx:pp=/mon/server-mon[server],type=WSClient,name=http-//localhost-8080/AddNumbersService/AddNumbersService

(Note that ':' characters have been replaced with '-'. See below for more info.)

19.3.2.2. User-assigned Client Monitoring Identifiers

To give a user-assigned identifier use the id attribute in the ManagedClient policy assertion.

19.3.3. Identifier Character Mapping

Some characters in a root name are converted to the '-' character. This is to avoid the need to quote characters that are not legal in JMX. The regular expression used to find and replace those characters is:

  "\n|\\|\"|\\*|\\?|:|=|,"

19.3.4. Resolving Monitoring Root Name Conflicts

It is possible that two root names can be the same. This can happen when deploying web services with the same service name and port name under different context paths in non-GlassFish containers because the context path is not available to the naming mechanism when in other containers. This can also happen when two different proxies are communicating with the same service.

When root names clash, then the rootname has -<N> appended, where N is a unique integer.


Terms of Use; Privacy Policy; Copyright ©2013-2014 (revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close