ObjectWeb Consortium
Print

Advanced Search - Powered by Google

  Consortium     Activities     Projects     Forge     Events 

Fractal


Project Links
· Home
· Documentation
· Download
· License
· What's New
· Wiki

Developers' Corner
· Workplan
· SVN Repository
· ObjectWeb Forge Site

About
· Team
· Users
· Partners
· Mailing List Archive




Fractal JMX Tutorial



AUTHOR :
       

N. Rivierre            (France Telecom R&D)

Version    0.2
Released   July 17, 2007




This document is a tutorial for Fractal JMX v0.2, a set of Fractal components that enable JMX management of Fractal applications through automatic exposition in JMX agents.

This version of Fractal JMX is based on the Fractal API and ADL specification v2.0, and the JavaTM Management extensions (JMXTM) Instrumentation and Agent Specification v1.2. Readers are expected to have a minimal knowledge of these specifications. Fractal JMX is not Julia dependant except for some additional and optional controllers that allow to equip Fractal components with basic statistics on method calls.

The Fractal JMX design has benefited from an initial study with an early prototype in 2003 by Laurent Andrey (Loria), Eric Bruneton, Thierry Coupaye and Ada Diaconescu (France Telecom R&D). It also uses material from JMX4ODP. This version is on an early stage and will evolve in the future.

Contents

1  Introduction
    1.1  Principle
    1.2  Naming convention
2  Instrumentation
    2.1  Comanche
    2.2  Instrumenting and browsing Comanche
    2.3  Simple scenarios
3  Monitoring
    3.1  String monitor
    3.2  Counter monitor
    3.3  Gauge monitor
Appendix A: ADL example (management profile)
Appendix B: Julia configuration with a stat-controller
Appendix C: Remote connexion
 
 
 

1  Introduction

This tutorial covers the steps required to run management-enabled Fractal applications using Fractal JMX. This section first introduces the principle and naming convention used in Fractal JMX. Section 2 and 3 illustrate how to instrument and monitor a Fractal application.

1.1 Principle

The resources that can be managed using Fractal JMX v0.2 are component server interfaces or monitors for observing component attributes. Fractal JMX does not impose intrusive management code or extra metadata to enable JMX management of these resources. The JMX agent level, responsible for delegating all the invocations between the management applications and the managed resources, is represented in Fractal JMX by a generic and autonomous Fractal agent component, whose only requirement is to be added in the Fractal application to be managed. This agent component enables JMX management of its host application by dynamically exploring the component structure and creating managed beans (MBeans) that represent either component server interfaces or monitors for observing component attributes.

Agent

The core component of Fractal JMX is the agent component that represents the JMX agent level. A Fractal application can be managed simply by adding the agent component in its structure. This Fractal agent component encapsulates a JMX MBeanServer and behaves as follows:

  • Its Admin interface specifies a single method ("expose") that allows to introspect components in the agent scope. Where the scope of the agent represents its super-components and all sub-components recursively enclosed in its super-components (or in itself if the agent has no super-components).
  • During the introspection, the agent dynamically creates and registers MBeans that represent either component server interfaces or standard JMX monitors for observing component attributes.
  • Since hundreds of MBeans can be generated during the introspection, the agent also provides an AdminAttributes interface that allows to filter the relevant MBeans, to avoid flooding of exposed information and performance penalty.

For example, in the architecture depicted below, where an agent is added to the composite B:

Figure 1

The component B, C, D and Agent (itself) are in the agent scope and then candidate to expose MBeans representing their server interfaces or observer on their attributes. The component A is not in the agent scope, and then cannot be managed, since it is not a super-component of the agent.

In practice, although it is possible to add several agents in a Fractal application, a typical way of using Fractal JMX is to add a single agent at the root composite level and to use its filter attributes to select the relevant MBeans.
 

Composite Agent

The primitive agent component included in the Fractal JMX distribution can be used alone. In practice, it is typically composed with listener and adaptor components before to be added in Fractal application to be managed:

  • A Listener component implements the NotificationListener interface and handles the notifications sent out by the attribute observers, if the agent is bound to this interface. It is intended to be customized if specific processing of the notifications is required.
  • An Adaptor component represents any additional MBean that needs to registers to the Agent component for specific (HTLM, RMI...) adaptation reason. Several adaptors can be used simultaneously. A typical case is an HTML adaptor, itself implemented as an MBean, that will allow an HTML browser to manage all MBeans in the agent.

A possible way of using these components together is depicted in the figure below.

Figure 2

This figure shows how these components can be bound to each other to get a functional composite Agent component, which provides an Admin interface. The resulting composite component (named AgentHost in the figure) behaves as an agent as far it provides an Admin interface, and can be added in a Fractal application to be managed
 

Default ADL

A default ADL definition of the agent architecture depicted in figure 2 is included in the Fractal JMX distribution. The composite template:

org.objectweb.fractal.jmx.AgentHost
contains the two following sub-components included in the Fractal JMX distribution:
  • the primitive agent component configured, by default, with its filter attributes set to "" (i.e. no MBean can be registered in the agent during introspection).
  • a basic listener component that writes to user screen the notifications received from the attribute observers. This component can be customized if specific processing of the notifications, sent out by the observers, is required.
This composite agent enables JMX management of Fractal applications, as illustrated below with Comanche.

NB. Since Fractal JMX v0.2, the following modifications have been introduced :
  • An HTML Adaptor component  has been removed  (due to licensing issues).
  • The jvm must be configured with the right arguments in order to make the Fractal JMX MBeanServer externally visible - so that remote rmi clients (e.g. Jconsole) can find it and use the available MBeans registered in this server (see appendix C).

1.2 Naming convention

In JMX, an ObjectName represents a reference to an MBean in the agent, or a pattern that can match the names of several MBeans It is unique within an MBeanServer and consists of two parts: the domain name and an unordered list of property-value pairs. The string representation of an object name must follow the following syntax:
[DomainName]:property=value[,property=value]*

In Fractal JMX, the object name of an MBean representing a component server interface uses this syntax as follows:

FC/[path]component@id[shared]:itf=interface
where:
  • component: is the name of the component, as returned by NameController.
  • interface: is the name of a server interface of the component, as returned by InterfaceType.
  • path: is a (slash separated) name sequence of the successive super-components of the component, in the reverse order.
  • shared: is set to "-shared" if the component may be identified by several paths (i.e. if the component or some component, in its super-component hierarchy, is shared).
  • id: is an inelegant, but unique, component identifier introduced to avoid JMX name clashes, since nothing prevents the same Fractal name sequence to identify several components.
For example, in the architecture depicted in figure 1, the MBean representing the interface I of the component D is named:
FC/A/B/C/D@56e32:itf=I
where @56e32 represents the unique identifier of component D. It is generated by the agent and can be ignored.

This naming convention:

  • requires components to have a NameController and to avoid (in component or interface names) characters interpreted in specific ways by ObjectName (e.g. ":", "*", "&"...).
  • is used by the agent attributes to filter the relevant MBeans. Only the MBeans, whose ObjectName matches a pattern defined by these attributes, are registered in the agent. These MBeans represent either component server interfaces or monitors for observing component attributes. In the latter case, the naming convention used by the agent attributes considers some additional property-value pairs reserved for the configuration of JMX monitors.

 

2  Instrumentation

This section illustrates how to instrument the Comanche application using Fractal JMX.

2.1 Comanche

Comanche is the minimal HTTP server introduced in "Developing with Fractal", whose component architecture can be summarized as follows:

archi.png
 
The version of Comanche used in this tutorial is unchanged, except for the component Logger that implements an additional attribute controller interface, specifying an "Header" attribute:
public interface LoggerAttributes extends AttributeController {
   String getHeader ();
   void setHeader (String header);
}

When Comanche is instanciated (see the example provided in the Fractal JMX distribution), open this URL in a web browser to display a simple test page:

http://localhost:8080/index.html

2.2  Instrumenting and browsing Comanche

In "Developing with Fractal", the ADL definition describing the root composite of Comanche is as follows (composed of the Frontend and the Backend sub-components):
<definition name="comanche.Comanche" extends="comanche.ComancheType">
<component name="fe" definition="comanche.Frontend"/>
<component name="be" definition="comanche.Backend"/>
<binding client="this.r" server="fe.r"/>
<binding client="fe.rh" server="be.rh"/>
</definition>

From section 1, a possible architecture for instrumenting all Comanche components is as follows (see appendix A for an alternative ADL definition that will allow to initialize the default values of the JMX component attributes):

<definition name="comanche.JmxComanche1" extends="comanche.Comanche">
<component name="agent"
definition="org.objectweb.fractal.jmx.AgentHost"/>
</definition>

The additional agent sub-component refers to the AgentHost composite template definition introduced in the default ADL section and depicted in figure 2. It is itself composed of two sub-components (a primitive agent and a basic listener) included in the JMX Fractal distribution.

Start the comanche example using "mvn -Prun" in "..\fractaljmx\examples\comanche". The jvm should be configured (see the maven pom file of this example) with:
  • the application argument set to: comanche.JmxComanche1
  • a JMX connector listening on port 1234 (see also appendix C)
Start Jconsole or your own rmi client to connect to the Fractal JMX MBeanServer. NB: if  you don't specify a process ID, Jconsole will automatically detect all local Java applications, and display a dialog box that lets you select the one you want to monitor.

fractal-agent-view0

Accept the connexion. Jconsole should provide the following page, where the following MBeans are registered (by default in Fractal JMX):
  • Agent:itf=admin                        represents the Admin interface of the agent component.
  • Agent:itf=attribute-controller    represents the AdminAttributes interface of the agent component.

fractal-agent-view2


2.3  Simple scenarios

This section illustrates how to expose component server interfaces with Fractal JMX, and then how to update component attributes and invoke component operations. The syntax of the agent attribute "ItfPatterns", used in this section for filtering component interfaces, is defined in the AdminAttributes interface as a sequence of (";" separated) string representations of ObjectName patterns. Only the component interfaces, whose ObjectName matches one of these patterns, can be registered in the agent.

First scenario

This scenario exposes all server interfaces of all Comanche components. The first step is to set the agent attribute "ItfPatterns", for filtering component interfaces:

  • browse the MBean "Agent:itf=attribute-controller" to display the attribute-controller interface (AdminAttributes) of the agent component.
  • set the filter attribute "ItfPatterns" with the value:
*:*
At this stage, the value of the filter attribute "ItfPatterns" represents a pattern that can match all component server interfaces. The second step is to register MBeans in the agent:
  • browse the MBean "Agent:itf=admin" to display agent component Admin interface.
  • click the "expose" operation's button to invoke this operation.
At this stage, all server interfaces of all Comanche components are registered in the agent and should be exposed. It is then possible to browse these interfaces in order to get/set components attributes or invoke component operations.

fractal-agent-view3


Second scenario

This scenario modifies the "Header" attribute of the logger component. This component is a sub-component of the Backend component, that in turn is a sub-component of the root composite of comanche (see Comanche). The first (optional) step is to select the relevant interfaces, to avoid flooding of exposed information:

  • browse the MBean "Agent:itf=attribute-controller".
  • set the filter attribute "ItfPatterns" with the value (see appendix A to initialize this value from an ADL definition, instead of modifying it from the browser):
*/l*:itf=attribute-controller;*/l*:itf=l
  • browse the MBean "Agent:itf=admin" and click the "expose" operation's button
At this stage, only the attribute-controller and the fonctional interfaces l of the logger component are registered in the agent.
 
fractal-agent-view4

The second (optional) step is check the current value of the "Header" attribute of the logger component (by default, the string "->").
  • browse the MBean "FC/JmxComanche/be/l:itf=l"
  • click its "log" operation's button. If the string "test" is used as argument, the following message should appear in the console:
-> test
The last step is to modify the header used by the logger:
  • browse the MBean "FC/JmxComanche/be/l:itf=attribute-controller".
  • set the attribute "Header" with the value:
foo
  • browse the MBean "FC/JmxComanche/be/l:itf=l" and click the "log" operation's button (again with the string "test" as argument). The following message should be printed in the console:
    foo test


3 Monitoring

This section illustrates how the standard JMX monitors (counter, gauge and string) can be used with Fractal JMX to observe component attributes of the Comanche application. Note that the listener component used in this section is the BasicListener (see the ADL definition "JmxComanche1"). This listener writes to user screen the notifications received from the observers. It can be customized if specific processing of the notifications is required.
 

3.1 String monitor

The standard JMX string monitor enables the observation of attributes of type String. It can be configured to trigger a notification when the observed attribute matches or differs from a compared string. In scenario 2, the "Header" attribute of the logger component of Comanche has been modified. This can be observed with Fractal JMX as follows:
  • browse the MBean "Agent:itf=adminAttributes".
  • set the filter attribute "MonitorStringPatterns" with the value (see appendix A to initialize this value from an ADL definition, instead of modifying it from the browser):
    *:itf=attribute-controller,observedAttribute=Header,granularityPeriod=5000,
      stringToCompare=foo,notifyDiffer=true,notifyMatch=true
  • browse the MBean "Agent:itf=admin" and click the "expose" operation's button
The syntax of this filter attribute "MonitorStringPatterns" is defined in AdminAttributes as a sequence of (";" separated) string representations of ObjectName patterns. Where the following properties are reserved for the configuration of a string monitor (as defined in the JMX specification):
  • observedAttribute: the attribute being observed.
  • granularityPeriod: the granularity period (in milliseconds).
  • stringToCompare: the string to compare with the observed attribute.
  • notifyDiffer: the differing notification's on/off switch value.
  • notifyMatch: the matching notification's on/off switch value.
The proposed value for the "MonitorStringPatterns" attribute represents a pattern that can match the attribute-controller interface of any component, if this interface specifies a string attribute "Header". This attribute will be monitored every 5000 ms and compared with the value "foo". Coming back to scenario 2, the following differ notification should be printed now in the console when the value of the "Header" attribute first differs from the value "foo" (subsequent differences from "foo" do not cause further notifications unless the attribute value matches "foo"):
*****  String Monitor
* NotificationType: jmx.monitor.string.differs
* Src: AgentService:type=stringMonitor,observer=1
* ObservedObject: FC/JmxComanche/be/l:itf=attribute-controller
* ObservedAttribute: Header
* Trigger: foo
* DerivedGauge: ->
*****
Similarly, the following match notification should be printed in the console when the value of the "Header" attribute first matches the value foo (subsequent matchings of "foo" do not cause further notifications unless the attribute value differs from "foo"):
*****  String Monitor
* NotificationType: jmx.monitor.string.matches
* Src: AgentService:type=stringMonitor,observer=1
* ObservedObject: FC/JmxComanche/be/l:itf=attribute-controller
* ObservedAttribute: Header
* Trigger: foo
* DerivedGauge: foo
*****
The format of these messages is described in BasicListener and relies on the information encapsulated in the received MonitorNotication.
 

3.2 Counter monitor

The standard JMX counter monitor observes the attributes that are integer types and behaves like counters. This section illustrates how counter monitors can be used with Fractal JMX to observe method calls that have been made on component server interfaces. Since the standard JMX monitors (counter, gauge and string) only allow to observe attributes (i.e. getter methods), this section also illustrates how to equip Fractal components with a stat-controller that exposes attributes representing statistics on method calls.

Note that the stat-controller implementations included in the Fractal JMX distribution i) are basic, and intended to be customized if more advanced statistics on method calls are required and ii) are the only part of Fractal JMX that is Julia dependant (see appendix B for a configuration example).


First scenario

In this scenario, we are interested to send a notification each time the number of method calls made on the logger component of Comanche reaches a threshold value. The first step is to equip this component with a stat-controller that exposes a "NumberOfMethodCall" attribute acting as a counter (this attribute is incremented each time a method call is made on the component). This can be done with the following ADL definition (where "statPrimitive" is an alias defined in the Julia configuration file, see appendix B):

<definition name="comanche.Logger" extends="comanche.LoggerType">
<content class="comanche.BasicLogger"/>
<attributes signature="comanche.LoggerAttributes">
<attribute name="Header" value="->"/>
</attributes>
<controller desc="statPrimitive"/> </definition>

The second step is to set the agent attribute for filtering counter monitor MBeans:

  • browse the MBean "Agent:itf=adminAttributes".
  • set the filter attribute "MonitorCounterPatterns" with the value (see appendix A to initialize this value from an ADL definition, instead of modifying it from the browser):
    *:itf=stat-controller,observedAttribute=NumberOfMethodCall,granularityPeriod=5000,
      initThreshold=2,modulus=0,offset=3,differenceMode=false
  • browse the MBean "Agent:itf=admin" and click the "expose" operation's button
The syntax of this filter attribute "MonitorCounterPatterns" is defined in AdminAttributes as a sequence of (";" separated) string representations of ObjectName patterns. Where the following properties are reserved for the configuration of a counter monitor (as defined in the JMX specification):
  • observedAttribute: the attribute being observed.
  • granularityPeriod: the granularity period (in milliseconds).
  • initThreshold: the initial threshold value.
  • modulus: the modulus value.
  • offset: the offset value.
  • differenceMode: the difference mode flag value.
The proposed value for the "MonitorCounterPatterns" attribute represents a pattern that can match the stat-controller interface of any component, if this interface specifies an integer attribute "NumberOfMethodCall" (as it the case for BasicStatController). This attribute will be monitored every 5000 ms, as defined in the JMX specification for a counter monitor configured with: InitThreshold=2, Modulus=0, Offset=3 and DifferenceMode=false.

Threshold notifications should be printed in the console when the value of this attribute reaches 2 (since the initial threshold equals 2) and then 5, 8, 11,...  (since the offset equals 3). This can be verified by iterating several times on the following sequence :

  • browse the MBean "FC/JmxComanche/be/l:itf=l"
  • click its "log" operation's button.
A more convenient alternative is to browse several times the commanche application (e.g. on http://localhost:8080/index.html). The logger component being equiped with a stat-controller, the following message should appear in the console when the "log" operation of the logger component is called the second time (i.e. when the "NumberOfMethodCall" attribute reaches 2):
*****  Counter Monitor
* NotificationType: jmx.monitor.counter.threshold
* Src: AgentService:type=counterMonitor,observer=1,attributeType=java.lang.Integer
* ObservedObject: FC/JmxComanche/be/l:itf=stat-controller
* ObservedAttribute: NumberOfMethodCall
* Trigger: 2
* DerivedGauge: 2
*****
Similar messages are printed when the "log" operation of the logger component is called 5, 8, 11,... times (since the counter monitor is configured with Offset=3). The format of these messages is described in BasicListener and relies on the information encapsulated in the received MonitorNotication.
 

Second scenario (throughput)

As defined in the JMX specification, the counter monitor can be configured (with the difference mode flag set to true) to send a threshold notification when the difference between two successive observations reaches a threshold value. Coming back on the previous scenario, it is then possible to observe if the number of calls to the "log" operation of the logger component reaches a given througput during a sampling period:

  • browse the MBean "Agent:itf=adminAttributes".
  • modify the filter attribute "CounterStringPatterns" as follows (see appendix A to initialize this value from an ADL definition, instead of modifying it from the browser):
    *:itf=stat-controller,observedAttribute=NumberOfMethodCall,granularityPeriod=5000,
      initThreshold=2,modulus=0,offset=0,differenceMode=true
  • browse the MBean "Agent:itf=admin" and click the "expose" operation's button
In this configuration, threshold notifications should be printed in the console each time the "log" operation of the logger component is called two (or more) times per sampling period of  5 seconds (since the difference mode equals true, the initial threshold equals 2 and the granularity period equals 5000 milliseconds). Another way of monitoring throuhput is explained in the next section.   
 

3.3 Gauge monitor

The standard JMX gauge monitor observes the attributes that are integer or floating point types and whose values fluctuate between high and low thresholds. This section illustrates how gauge monitors can be used with Fractal JMX to observe the througput of method calls that have been made on component server interfaces. As explained for counter monitor, the first step is to use a stat-controller that exposes attributes representing statistics on method calls that have been made on the server interfaces of a component. The second step is to set the agent attribute for filtering gauge monitor MBeans:
  • browse the MBean "Agent:itf=adminAttributes".
  • set the filter attribute "MonitorGaugePatterns" with the value (see appendix A to initialize this value from an ADL definition, instead of modifying it from the browser):
    *:itf=stat-controller,observedAttribute=RateOfMethodCall,granularityPeriod=5000,
      lowThreshold=0.01,highThreshold=0.3,differenceMode=false
  • browse the MBean "Agent:itf=admin" and click the "expose" operation's button
The syntax of this filter attribute "MonitorCounterPatterns" is defined in AdminAttributes as a sequence of (";" separated) string representations of ObjectName patterns. Where the following properties are reserved for the configuration of a gauge monitor (as defined in the JMX specification):
  • observedAttribute: the attribute being observed.
  • granularityPeriod: the granularity period (in milliseconds).
  • lowThreshold: the low threshold value.
  • highThreshold: the high threshold value.
  • differenceMode: the difference mode flag value.
The proposed value for the attribute filter represents a pattern that can match the stat-controller interface of any component, if this interface specifies an integer or floating point attribute "RateOfMethodCall" (as it the case for BasicStatController). This attribute will be monitored every 5000 ms, as defined in the JMX specification for a gauge monitor configured with: LowThreshold=0.01, HighThreshold=0.3,  and DifferenceMode=false.

Coming back to the counter monitor scenarios, the following threshold low notification should be printed now in the console (at the begining of the session):

*****  Gauge Monitor
* NotificationType: jmx.monitor.gauge.low
* Src: AgentService:type=counterMonitor,observer=1,attributeType=java.lang.Integer
* ObservedObject: FC/JmxComanche/be/l:itf=stat-controller
* ObservedAttribute: RateOfMethodCall
* Trigger: 0.01
* DerivedGauge: 0.0
*****
This is normal since the "log" operation of the logger component has not be called. The gauge monitor has a low threshold equals to 0.01 when the observed attribute "RateOfMethodCall" of the stat-controller (representing the throuhput observed during the last period) equals 0.

Similarly, a threshold high notification should be printed in the console when the "log" operation of the logger component is called several times (e.g. by browsing several times the commanche application on http://localhost:8080/index.html). For example:

*****  Gauge Monitor
* NotificationType: jmx.monitor.gauge.high
* Src: AgentService:type=counterMonitor,observer=1,attributeType=java.lang.Integer
* ObservedObject: FC/JmxComanche/be/l:itf=stat-controller
* ObservedAttribute: RateOfMethodCall
* Trigger: 0.3
* DerivedGauge: 0.587
*****
The gauge monitor has a high threshold equals to 0.3 when the observed attribute "RateOfMethodCall" of the stat-controller (representing the throuhput observed during the last period) equals 0.587 calls per second.

The format of these messages is described in BasicListener and relies on the information encapsulated in the received MonitorNotication.
 
 
 

Appendix A: ADL example (management profile)

This appendix illustrates how to define a management profile with Fractal JMX. This can be done by initializing the Fractal JMX component attributes from an ADL definition, instead of modifying them from the browser. This new ADL definition of the Comanche root composite (named now "JmxComanche2") has to be compared with the versions proposed in section 2.2.

The JmxComanche2 definition is similar to the JmxComanche1 definition proposed in section 2.2, i.e. it contains an additional agent sub-component composed of two sub-components (a primitive agent and a basic listener) as depicted in figure 2. The only differences come from the attributes of the primitive agent that are overloaded to filter the relevant MBeans, as described in this tutorial.
<definition name="comanche.JmxComanche2" extends="comanche.Comanche">
  <component name="agent" definition="org.objectweb.fractal.jmx.AgentHost">
<component name="agent">
<attributes>
<attribute name="ItfPatterns" value="*/l*:itf=attribute-controller;*/l*:itf=l"/>
<attribute name="MonitorStringPatterns"
value="*:itf=attribute-controller, // WARNING: This string value is
observedAttribute=Header, // formated only for documentation
granularityPeriod=5000, // purpose. Remove this comment,
stringToCompare=foo, // white spaces and carriage returns
notifyDiffer=true, // in actual Fractal ADL files.
notifyMatch=true"/>
<attribute name="MonitorCounterPatterns"
value="*:itf=stat-controller, // WARNING: see above
observedAttribute=NumberOfMethodCall,
granularityPeriod=5000,
initThreshold=2,
modulus=0,
offset=3,
differenceMode=false"/>
<attribute name="MonitorGaugePatterns"
value="*:itf=stat-controller, // WARNING: see above
observedAttribute=RateOfMethodCall,
granularityPeriod=5000,
lowThreshold=0.01,
highThreshold=0.3,
differenceMode=false"/>
</attributes>
</component>
</component>
</definition>

Using this ADL definition,
Jconsole should provides the following page after starting the session:


Browse the MBean "Agent:itf=admin" and click the "expose" operation's button to activate the management profile. This way the ressources and monitors described in the previous section are automatically exposed and activated.
 

Appendix B: Julia configuration with a stat-controller

The "statPrimitive" alias can be defined as follows in the Julia configuration file. It is similar to the usual "Primitive" alias except for an additional BasicStatController included in the Fractal JMX distribution. This controller:
  • implements the StatController interface and must be associated with the StatCodeGenerator that generates interception code.
  • can be configured with a parameter representing the minimal time interval used for rate re-computation, in milliseconds (the proposed value is 5000).
  • can be replaced by the ExponentialSmoothingStatController (also included in the Fractal JMX distribution) that uses a basic exponential smoothing method for rate computation. A second parameter is then available to adjust the smoothing constant used by this implementation (the proposed value is 0.5). 
    (statPrimitive
      (
        'interface-class-generator
        (
          'component-itf
          'binding-controller-itf
          'super-controller-itf
          # only if super-controller-itf does not designate the Julia interface:
          # 'julia-super-controller-itf
          'lifecycle-controller-itf
          # only if lifecycle-controller-itf does not designate the Julia interface:
          # 'julia-lifecycle-controller-itf
          'name-controller-itf
          (stat-controller org.objectweb.fractal.jmx.julia.stat.StatController)
        )
        (
          'component-impl
          'container-binding-controller-impl
          'super-controller-impl
          'lifecycle-controller-impl
          'name-controller-impl
          (org.objectweb.fractal.jmx.julia.stat.BasicStatController 5000)
          # (org.objectweb.fractal.jmx.julia.stat.ExponentialSmoothingStatController 5000 0.5)
        )
        (
          (org.objectweb.fractal.julia.asm.InterceptorClassGenerator
            org.objectweb.fractal.julia.asm.LifeCycleCodeGenerator
            org.objectweb.fractal.jmx.julia.stat.StatCodeGenerator
          )
        )
        org.objectweb.fractal.julia.asm.MergeClassGenerator
        'optimizationLevel
      )
    )

    Appendix C: Remote connexion

    The jvm must be configured with the right arguments in order to make the Fractal JMX MBeanServer externally visible - so that remote rmi clients (e.g. Jconsole) can find it and use the available MBeans registered in this server.

    For example, you can use the following arguments to start the jvm with a JMX remote agent enabled, with no authentication or ssl security and with a JMX connector listening on port 1234:
            -Dcom.sun.management.jmxremote.port=1234
            -Dcom.sun.management.jmxremote.authenticate=false

            -Dcom.sun.management.jmxremote.ssl=false

    These arguments are well-explained in the j2se documentation (e.g. for j2se 1.5 from here or for j2se 1.6 from here).

    This is illustrated in the comanche example of Fractal JMX, which can be managed with Jconsole or your own rmi client. The maven configuration of the remote connexion part of this example should look like:

            ...      
            <systemProperties>

                  ...
                  <systemProperty>
                     <key>com.sun.management.jmxremote.port</key>
                     <value>1234</value>
                  </systemProperty>
                  <systemProperty>
                     <key>com.sun.management.jmxremote.authenticate</key>
                     <value>false</value>
                  </systemProperty>
                     <systemProperty>
                     <key>com.sun.management.jmxremote.ssl</key>
                  <value>false</value>
                  </systemProperty>
                  ....
            </systemProperties>


    NB: Using maven with
    j2se 1.5 requires to set the MAVEN_OPTS environment variable with these jvm arguments (this is not required with j2se 1.6).

    MAVEN_OPTS=-Dcom.sun.management.jmxremote.port=1234
               -Dcom.sun.management.jmxremote.authenticate=false
               -Dcom.sun.management.jmxremote.ssl=false



Copyright © 1999-2009, OW2 Consortium | contact | webmaster | Last modified at 2012-12-03 09:57 PM