How to enable/disable monitoring and attach btrace-agent in GlassFish v3

Wednesday Sep 09, 2009

The monitoring funcationality including attaching btrace-agent is done based on the 'monitoring-enabled' attribute of 'monitoring-service' element. If monitoring-enabled is true then the btrace-agent is attached as part of startup. When monitoring-enabled is false, btrace-agent is not attached at startup time. However when user changes monitoring-enabled to true while the server is running, it should be possible to attach the btrace-agent and start monitoring functionality.

Purpose of this pair of commands is to provide enable /disable monitoring during run time without having to restart the server (Alternatively user should be able to use asadmin set command to enbale/disable the monitoring-enabled flag, but have to restart the server to take effect). It does attach btrace-agent based on the given pid and optionally sets the monitoring level for given modules.

enable-monitoring

enable-monitoring [--mbean=false] [--dtrace*=true] [--level web-container="LOW":ejb-container="HIGH"] [--options="debug=true"] [--pid=<pid>]

• enable-monitoring
  sets the attribute 'monitoring-enabled' to 'true'
• enable-monitoring --mbean=true --dtrace*=false
  sets the attribute 'monitoring-enabled' to 'true', mbean-enabled to true and dtrace-enabled to false
• enable-monitoring --options="debug=true" --pid=<pid>
  sets the attribute 'monitoring-enabled' to 'true' and attaches btrace agent using --options
• enable-monitoring --level web-container="LOW":ejb="HIGH"
  sets the levels for given modules in addition to 'monitoring-enabled'

disable-monitoring

disable-monitoring --modules="web-container,ejb-container"

• disable-monitoring
  sets the attribute 'monitoring-enabled' to 'false'
• disable-monitoring --modules="web-container,ejb-container"
  this command will just set the levels for given modules to 'OFF' and it does not change the value for 'monitoring-enabled'

*- Available as a value-add feature, made available only to the paid customers.

Above also caters an important use case of adhoc monitoring, i.e. turning monitoring on in production while server is running, for ex. enable dtrace on the fly.

GlassFish Bootcamp Handson Lab 10mar09

Sunday Mar 08, 2009

Sreenivas Munnangi & Anissa Lam

The lab consists of 4 tasks and it starts with an easy one :-)
Prior to starting the lab, install and start application server. Call the install location of application server as <as-root>

Task_1: webservices sample deployment and testing

download pkghello-web.war and save it under, let us say <sample-root> directory

01 Connect to admin console from a browser using http://localhost:4848/

02 Deploy webservices application
   - select 'Web Applications' from the left navigation menu
   - Click <Deploy> button on the right
   - provide location of the sample file pkghello-web.war
   - scroll down and select 'server' as target
   - click on <OK> for deployment
   - observe the server.log <install_root>/domains/domain1/logs/server.log

03 Test the deployed webservices application
   - select 'Web Services', 'Hello' from the left navigation menu
   - click on <Test> button in the right window
   - above action pops up a window with links
   - click on the first link which points to 8080
   - experiment with the sample by inputting appropriate values


Task_2: webservices sample monitoring

01 Turn on monitoring for webservices
   - select 'Web Services', 'Hello' from the left navigation menu
   - select 'Monitor' tab in the right window
   - select 'Configuration' tab underneath 'Monitor' tab
   - change 'Monitoring Level' to 'High' and click on <Save> button

02 Monitor webservices application
   - gather monitoring data by experimenting with webservices application as described in item 03 above under task_1
   - select 'Statistics' tab underneath 'Monitor' tab
   - observe different monitoring stats
   - select 'Messages' tab underneath 'Monitor' tab
   - click on 'Time Stamp' url and notice the request/response messages


Task_3:Deploy, manage and Monitor using CLI

01 Define environment variables
    AS_ADMIN_HOST=localhost
  AS_ADMIN_PORT=4848
  AS_ADMIN_USER=admin

02  Remember that the default admin password is 'adminadmin'

03 Deploy web application
  download cli-hello.war and save it under, let us say <sample-root> directory
  > cd <as-root>/bin
 > asadmin deploy <sample-root>/cli-hello.war
 > asadmin list-components

04 Turn the monitoring on for web applications
 > asadmin get "server-config.monitoring-service.module-monitoring-levels.*"
 > asadmin set "server-config.monitoring-service.module-monitoring-levels.http-service=HIGH"
 > asadmin set "server-config.monitoring-service.module-monitoring-levels.web-container=HIGH"

05 Monitor the web application similar to 'top' in unix
   > asadmin monitor --type webmodule --filter //server/cli-hello server
   use key <h> for help on column titles
   use key <q> to quit
   > access the web application using a browser
   > http://localhost:8080/cli-hello, as you experiment with the application, notice how the asadmin monitor values change

Task_4: Create a cluster and deploy a web application
01 Create and start node agent in a terminal using CLI
  > asadmin create-node-agent agent1
  > asadmin start-node-agent agent1

02 Create and start a cluster using Admin Console
 > click on 'Create New Cluster' in the Common Tasks Page
 > enter name of the cluster
 > click  <New...> in the Server Instances table, enter instance name and node agent
 > click <New...> again to add another server instance
 > click <OK> button to create this cluster with 2 instances
  > in the Clusters table, select this cluster and press 'Start Cluster' button.

03 Deploy Web Application
 > expand 'Clusters' in tree node and select the cluster
 > go to Applications tab and click <Deploy...> button
 > scroll down and observe that this cluster is preselected as the 'target'.
 > enter application location and press <OK> button.

How to make Grizzly Comet work with Java Client instead of Web Client

Thursday Feb 19, 2009

There are many examples illustrating the usage of Grizzly Comet for Web Client but not for Stand alone java client. I needed one and with help from Jeanfrancois Arcand, users@grizzly.dev.java.net and my colleague Prashant Abbagani, I came up with the following example.

Conventionally the client either polls or pulls the message from server periodically, the draw back with this approach is that the client wastes the resources and the messages may not be received in real time. Instead, in comet approach, the server pushes the messages to client in real time. For this example, I have used GlassFish v3 which comes bundled with Grizzly and Comet. Here are the steps:

• Download and install GlassFish v3.
   
  
• Enable comet support in GlassFish v3.

          ...
          <http-listener port="8080" id="http-listener-1" address="0.0.0.0" default-virtual-server="server" server-name="">
            <property name="cometSupport" value="true" />
          <http-listener>
          ...
  

• Develop and deploy comet.war to push messages from server to client. You may like to refer to MyCometServlet.java source code.
   
  
• Code the client CometClient.java and listen for server messages.

  Start the client.

  punit[105]: java CometClient
  init ...
  

• Simulate posting messages to server using Post2CometServlet.java.

  Post message to server

  punit[54]: java Post2CometServlet
  punit[55]: java Post2CometServlet
  punit[56]: java Post2CometServlet
  punit[57]: java Post2CometServlet
  punit[58]: java Post2CometServlet
  

  The client output gets updated in real time as the messages are posted to the servlet.

  punit[105]: java CometClient
  init ...my message sent at 1235082867986
  my message sent at 1235082891002
  my message sent at 1235082892018
  my message sent at 1235082893714
  my message sent at 1235082894420
  

Proxy pattern for exposing jsr77 api and internal api using common implementation

Wednesday Feb 18, 2009

GlassFish v3 is designed to be modular not only in architecture but in distribution as well. The distributions range from compact version 'Nucleus' to full blown version 'Enterprise' through 'Web', and 'PE' distributions.

We need to support jsr77 in Enterprise version so we'll need jsr77 interfaces to be available only in Enterprise version and not the lower versions like 'Web' and 'PE'. However we need to use jsr77 like monitoring data types for exposing monitoring data in 'Web' and 'PE' distributions. This poses a challenge of maintaining same data types but in two different packages. To avoid this maintenance hassle, we can use proxy pattern as described below.

Assume that we need to expose two interfaces with different package names but with same method signatures. Let us call them javax.management.j2ee.statistics.Statistic and org.glassfish.internal.api.Statistic. The corresponding implementations are javax.management.j2ee.statistics.JSR77StatisticImpl and org.glassfish.internal.api.IntStatisticImpl respectively. Recall that our idea of using proxy pattern is to avoid the maintenance hassle and for that we make JSR77StatisticImpl extend IntStatisticImpl and implement javax.management.j2ee.statistics.Statistic. This makes it reuse the common implementation.

Using dynamic proxy api, we can expose the required interface at runtime as shown below with working example.

• Create glassfish internal Statistic interface under <stats_proxy_pattern>/internal-api
   
  
• Create glassfish internal Statistic implementation IntStatisticImpl under <stats_proxy_pattern>/internal-api
   
  
• Create jsr77 Statistic interface under <stats_proxy_pattern>/jsr77
   
  
• Create jsr77 Statistic implementation JSR77StatisticImpl under <stats_proxy_pattern>/jsr77
   
  
• Create StatsProxy under <stats_proxy_pattern>/monitor
   
  
• First let us test the internal Statistic data type using the following code under <stats_proxy_pattern>.

  import org.glassfish.internal.api.*;
  import com.sun.enterprise.monitor.*;
  
  /**
   * Verify the stat types at runtime
   * @author Sreenivas Munnangi
   */
  
  public class TestStatInterface {
      public static void main (String args[]) {
          System.out.println("TestStatInterface");
          try {
              //interanl Statistic
              Statistic stat = (Statistic) StatsProxy.newInstance(new IntStatisticImpl());
              System.out.println("TestStatInterface: before calling method getName on proxy ...");
              System.out.println("TestStatInterface: stat.getName() = " + stat.getName());
              System.out.println("TestStatInterface: after calling method getName on proxy ...");
              System.out.println("TestStatInterface: before calling method getStartTime on proxy ...");
              System.out.println("TestStatInterface: stat.getStartTime() = " + stat.getStartTime());
              System.out.println("TestStatInterface: after calling method getStartTime on proxy ...");
          } catch (Exception e) {
              System.out.println("Caught exception ...");
              e.printStackTrace();
          }
      }
  }
  
  When we build and run the above code, we see the following output. 
  I have used build.xml from the attached example, 
  link is provided at the end of this blog.
  
  run:
       [java] TestStatInterface
       [java] TestStatInterface: before calling method getName on proxy ...
       [java] statsproxy before method getName
       [java] result = called getName() ...
       [java] statsproxy after method getName
  
       [java] TestStatInterface: stat.getName() = called getName() ...
       [java] TestStatInterface: after calling method getName on proxy ...
       [java] TestStatInterface: before calling method getStartTime on proxy ...
       [java] statsproxy before method getStartTime
       [java] result = 1234985924526
       [java] statsproxy after method getStartTime
       [java] TestStatInterface: stat.getStartTime() = 1234985924526
       [java] TestStatInterface: after calling method getStartTime on proxy ...
  
  BUILD SUCCESSFUL
  

• Now test for jsr77 Statistic type. Notice the change in imports.

  import javax.management.j2ee.statistics.*;
  import com.sun.enterprise.monitor.*;
  
  /**
   * Verify the stat types at runtime
   * @author Sreenivas Munnangi
   */
  
  public class TestStatInterface {
      public static void main (String args[]) {
          System.out.println("TestStatInterface");
          try {
              //jsr77 Statistic
              Statistic stat = (Statistic) StatsProxy.newInstance(new JSR77StatisticImpl());
              System.out.println("TestStatInterface: before calling method getName on proxy ...");
              System.out.println("TestStatInterface: stat.getName() = " + stat.getName());
              System.out.println("TestStatInterface: after calling method getName on proxy ...");
              System.out.println("TestStatInterface: before calling method getStartTime on proxy ...");
              System.out.println("TestStatInterface: stat.getStartTime() = " + stat.getStartTime());
              System.out.println("TestStatInterface: after calling method getStartTime on proxy ...");
          } catch (Exception e) {
              System.out.println("Caught exception ...");
              e.printStackTrace();
          }
      }
  }
  
  Following is the output which will be similar to what 
  we have seen earlier since they both use common implementation.
  
  run:
       [java] TestStatInterface
       [java] TestStatInterface: before calling method getName on proxy ...
       [java] statsproxy before method getName
       [java] result = called getName() ...
       [java] statsproxy after method getName
       [java] TestStatInterface: stat.getName() = called getName() ...
       [java] TestStatInterface: after calling method getName on proxy ...
       [java] TestStatInterface: before calling method getStartTime on proxy ...
       [java] statsproxy before method getStartTime
       [java] result = 1234986155422
       [java] statsproxy after method getStartTime
       [java] TestStatInterface: stat.getStartTime() = 1234986155422
       [java] TestStatInterface: after calling method getStartTime on proxy ...
  
  BUILD SUCCESSFUL
  

Download the complete example.

Extending GlassFish v3 Prelude, As Easy As 1-2-3

Thursday Nov 06, 2008

Now it is possible, with more ease than ever to write your own add-on and extend the functionality of GlassFish v3 Prelude application server.

From scratch, GlassFish v3 is designed to be modular, this combined with HK2 component services and OSGi module system made extensibility more natural for Prelude version.

For example, to extend the GlassFish server functionality by providing an add-on, one would need support for configuration, runtime, monitoring and administration. It is much better if it allows smoother integration like GlassFish modules themselves. Precisely, this is what the pluggable infrastructure provides.

In this series, I plan to explain various pluggability features provided by v3 with examples of working code where appropriate.

Some of the pluggability features available presently are:

• Admin CLI (Command Line Interface)
• Monitoring
• Deployment
• Container
• Configuration
• OEM Branding

In this blog, I'll discuss about Admin CLI pluggability. The asadmin utility is a command-line tool for configuring and administering the application server. By using CLI pluggability, the add-on could implement its own CLI commands similar to application server.

Declaration of CLI Command

@Service(name="mycommand")
@Scoped(PerLookup.class)
public class CLIPluggabilityCommand implements AdminCommand {
...
}

The CLI command will be implemented as a service using the annotation @Service and by implementing the AdminCommand interface. This enables run time discovery of the command. The command name is mycommand which is declared as part of @Service annotation. The scope is defined by the annotation @Scoped, PerLookup means whenever the command is looked up a new instance of the command is created and Singelton retains the same command for the entire session.

Parameters

The CLI command usually includes options and operands which are passed as parameters. For example, asadmin mycommand os has operand os which is paased to the command as @Param annotation.

    ...
    // this value can be either runtime or os for our demo
    @Param(primary=true)
    String inParam;
    ...

Execute method

    public void execute(AdminCommandContext context) {

        ActionReport report = context.getActionReport();
        report.setActionExitCode(ExitCode.SUCCESS);

        // If the inParam is 'os' then this command returns operating system info
        // and if the inParam is 'runtime' then it returns runtime info.
        // Both of the above are based on mxbeans.
 
        if ("os".equals(inParam)) {
            OperatingSystemMXBean osmb = ManagementFactory.getOperatingSystemMXBean();
            report.setMessage("Your machine operating system name = " + osmb.getName());
        } else if ("runtime".equals(inParam)) {
            RuntimeMXBean rtmb = ManagementFactory.getRuntimeMXBean();
            report.setMessage("Your JVM name = " + rtmb.getVmName());
        } else {
            report.setActionExitCode(ExitCode.FAILURE);
            report.setMessage("operand should be either 'os' or 'runtime'");
        }

Implement the execute method based on inParam. The ActionReport which is obtained from AdminCommandContext is used to return the command status or error message to the client.

Complete Example

To work with the example, following are the steps:

• Checkout and build GlassFish v3
• Download pluggability-cli.zip and expand it under GlassFish v3 source directory
• cd v3/pluggability/cli
• mvn clean install
• copy target/cli-pluggability-example-3.0-SNAPSHOT.jar to glassfish-install-location/modules
• start glassfish
• asadmin mycommand os should display the operating system name of the machine on which application server is run

Example log

punit[146]: ./asadmin list-commands | grep mycommand
delete-jvm-options                      mycommand

punit[150]: ./asadmin help mycommand

Administration Commands                        mycommand (1)

NAME
     mycommand - command to get application server os/runtime info.
...

punit[136]: ./asadmin mycommand abc
remote failure: operand should be either 'os' or 'runtime'

Command mycommand failed.

punit[137]: ./asadmin mycommand os
Your machine operating system name = SunOS

Command mycommand executed successfully.

punit[138]: ./asadmin mycommand runtime
Your JVM name = Java HotSpot(TM) Server VM

...

[2] Comments

• Nice blog. This is a good example of illustrating...

• Nice!

• Post a comment

Like this post? | | | |

Posted at 10:26AM Nov 06, 2008 by msreddy in Sun
Tags: glassfish v3