Wednesday Sep 09, 2009

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

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.

Sunday Mar 08, 2009

GlassFish Bootcamp Handson Lab 10mar09

bootcamp_10mar09_mnm 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.

Thursday Feb 19, 2009

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

comet_client 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
    

Wednesday Feb 18, 2009

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

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.

Thursday Nov 06, 2008

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

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

...

Wednesday Oct 10, 2007

Application Server N1SPS Plugin - Blogs and Resources

Thanks to Prashanth, Jane and Rajeshwar for the contributions. This is meant to be a collection of blogs and resources so that interested user has one place to start with.

Download N1SPS 6.0 Application Server Plugin

Blogs on Application Server N1SPS Plugin:

N1SPS Resources:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-1763394-3"; urchinTracker(); </script>

Application Server Configuration Using N1SPS Plugin's asadmin Component

Configuration of the Application Server is done mostly using the predefined components under the 'Configuration Tasks Node' of Application Server Plugin Navigation Menu. For details, please refer to Prashant's blog on the Plugin Tasks. It is also possible to configure the Application Server using Generic asadmin component under 'Other Tasks'. This blog will explain the use of generic asadmin component for configuring Application Server. Here are the steps for configuring maximum heap size, steps are similar for configuring other options as well.

01. Determine the current Value

Determine the current value corresponding to maximum heap size JVM Options using admin console.
 

From the above image, we can see that the current value is "-Xmx512m" which we would like to increase to 1024m (1 GB).
 

02. Delete the existing JVM option

The equivalent asadmin command for deleting the jvm option is 'asadmin delete-jvm-options -- -Xmx512m'.
 

Select 'Other Tasks' from the Plugin navigation menu and 'Remote Command' on the right.
 

Provide the values for host, select 'Edit Variable Set' and define new variable set called 'delete_heap_512m' as shown below.
 

Click on 'Save' and 'Run' on the main window.
 

03. Create new JVM option

The equivalent asadmin command for creating the jvm option is 'asadmin create-jvm-options -- -Xmx1024m'.
Select 'Other Tasks' from the Plugin navigation menu and 'Remote Command' on the right.
 

Provide the values for host, select 'Edit Variable Set' and define new variable set called 'create_heap_1024m'.

Click on 'Save' and 'Run' on the main window.
 

04. Verify the new Value

Determine the new value corresponding to maximum heap size JVM Options using admin console.
 


 

For additional resources, please refer to Application Server N1SPS Plugin - Blogs and Resources

Application Server 6.0 N1SPS Plugin - Deployment of Applications

For a basic understanding of Provisioning using Application Server 6.0 N1SPS Plugin and the supported versions, please refer to Jane Young's blog on Using N1SPS in GlassFish V2 Enterprise Environment and Prashant's blog on Provisioning GlassFish V2 with N1SPS. Here I try to explain how the Java EE (j2ee) Applications/Modules can be deployed or undeployed using the plugin.

To deploy an application, first create a deployment component to upload the application archive to the master server repository and then use that component to deploy the application. Here are the steps:
 

01 Create a folder to hold the component

Click on 'Manage Plans and Components' on the left and choose 'Folders' tab.
 


 

Click on 'New Folder' which will bring up a 'New Folder Wizard'. Provide the information needed by wizard, such as 'Folder Name'. In our case, let us call it 'Deploy'. Once the folder is created successfully, you'll see it on the left.
 

02 Create deployment Component

Drop down the tree in the left pane under 'Manage Applications' until you see 'Application Server'. Click on 'Application Tasks' and select 'Create Application Component' which will bring up a 'New Component Wizard'.
 


 

Provide component name and folder.
 


 

Now provide server name and deployment application archive details.
 


 

03 Deploy the Application

Using the deployment component created above, let us deploy the application. Select 'Manage Plans and Components' from the left navigation menu. Click on 'Deploy' folder. Click on 'Components' tab on the right and notice the 'deploy' component.
 


 

Click on 'deploy' component, select 'Variable Sets' tab, and click on 'New Variable Set' which will open a 'New Variable Set' wizard. Provide the required information and 'save'.
 


 

Select 'Procedures' tab on the right and check 'install:default' to deploy the application. Now click on 'Run Procedure', provide the required information and click on 'Run' which will deploy the application.
 


 

Successful deployment can be verified by examinig the 'Hosts' table on 'Where Installed' tab.
 


 

04 Undeploy the Application
 

To undeploy the application, check 'uninstall:defau;t' on 'Procedures' tab, select the host and click on 'Run Selected Installation'
 


 

Now select 'Run'
Successful undeployment can be verified by examinig the 'Hosts' table on 'Where Installed' tab.
 


 

The deployment and undeployment of applications/modules can also be done using generic asadmin component. For details, please see my blog on Support for asadmin command in Application Server 6.0 N1SPS Plugin.


 

For additional resources, please refer to Application Server N1SPS Plugin - Blogs and Resources

Monday Sep 17, 2007

Support for asadmin command in Application Server 6.0 N1SPS Plugin

The Sun Java System Application Server (SJSAS) plugin 6.0 (available oct'07) for N1SPS provides support for running generic asadmin command in remote and local modes. The existing plugin provides components and plans to meet several common requirements. However in some cases where the specific functionality is not exposed thru the above components and plans, the generic asadmin command component can be used.

The asadmin component comes in 2 flavors, remote and local. By remote, the commands are communicated via http/s to DAS and needs the command name and arguments, the admin user id, password, host name and port are automatically provided. The local command doesn't need the admin user id, and password so no values are automatically provided to the local command.

In addition to running adhoc asadmin commands, it is possible to save the commands for repeated/later use by using 'Create Component' version of Remote and Local commands.

Pl. see the image below to visualize the N1SPS admin console support for asadmin commands under the category of 'Other Tasks'.

Remote Command: This procedure allows user to execute an asadmin remote command on multiple domains as the targetable host. The required variable is "asadminCommand" and "asadminArguments" is optional.

Create Remote asadmin Component: This procedure popups a wizard for user to create a custom component from the generic asadmin remote component. User can name the component to easily identify the asadmin command and can be tracked in the "Activity Log". User can overwrite the variables "asadminCommand" and "asadminArguments". When executing the custom component, user will not required to create a variable set since the default values already contain the values that are required to execute the command.

Local Command: The procedure is similar to the "Remote Command" except the asadmin is executed locally. The targetable host is the AppServer Install virtual host name.

Create Local asadmin Component: This procedure is similar to the "Create Remote asadmin Component" except the custom component created is for executing asadmin command locally.

To understand how the provisiong works with the Application Server, pl. refer to Prashant's blog on Provisioning GlassFish V2 with N1SPS.

I would like to thank Jane Young for providing certain content for the above blog.

Monday Apr 30, 2007

Fish for a Flat-Screen TV Contest

Fish for a Flat Screen TV
Blog about GlassFish for a chance to win a 52" LCD HD TV. » More

Blog About GlassFish for a Chance to Win a 52-Inch LCD HD TV

.

GlassFish V2 is a production-ready, open-source Java EE 5 application server currently in beta.

GlassFish: The Clear Choice for the Web

  • Simplified development with the Java EE 5 platform
  • Includes Enterprise JavaBeans (EJB) 3.0, JavaServer Faces (JSF) 1.2, JavaServer Pages (JSP) 2.1, Java Servlet 2.5, Java API for XML Web Services (JAX-WS) 2.1 and Java Architecture for XML Binding (JAXB) 2.1 technologies.
  • Vibrant ecosystem with over 26 projects
  • Open source General Public License (GPL) and Common Development and Distribution License (CDDL)
  • Free for download and deployment
  • More than 6900 members and over 2.5 million downloads
  • Support:java.sun.com/javaee/support
  • Adoption:blogs.sun.com/stories
  • News:blogs.sun.com/theaquarium

GlassFish V2 provides features like clustering, high availability (HA), load balancing, Microsoft Interoperability with Web Services Interoperability Technology (WSIT), great price/performance, next-generation Web with Ajax, Scripting and RESTful web services, NetBeans IDE integration, SOA support through Java Business Integration (JBI) for service-oriented architecture (SOA). It is available for download today.

We want application server developers, administrators, and enterprise users to experience GlassFish V2 Beta and its exciting features. Submit your blog for a chance to win a 52-Inch LCD HD TV. Contest runs May 1st through June 15th, 2007.

Contest Details:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-1763394-1"; urchinTracker(); </script>
About

msreddy

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today