Thursday Dec 10, 2009

How to use GlassFish v3 DTrace probes on Solaris

Use of  Enterprise Manager DTrace Monitoring 3.0 beta value-add, exposes GlassFish v3 monitoring probes as DTrace probes on solaris platforms. D scripts can span multiple layers. In a given application, some of the modules might take too much time. You want to know how much time each module is taking so that you can quickly isolate the slow module. The following example shows the amount of time taken by each module. This can be easily extended to other modules/layers like MySQL, Solaris OS, etc. In future articles, I'll blog about this.
  • Install JDK7 and set JAVA_HOME to point to this location.
  • Download and install GlassFish v3, let us call the install location <gfv3>
  • Download DTrace value-add: DTrace Monitoring is available under an evaluation licence from the Sun GlassFish Enterprise Manager DTrace Monitoring download page.
  • cd <dtrace download directory>
  • unzip monitoring_dtrace-3_0-beta.zip
  • cp monitoring_dtrace/lib/glassfish-dtrace.jar <gfv3>/modules
  • Start GlassFish v3 using asadmin start-domain domain
  • Enable dtrace using asadmin set configs.config.server-config.monitoring-service.dtrace-enabled=true
  • Download and Deploy the sample ejb-web application using asadmin deploy stateless-converter.ear
  • In another terminal, login as super user or any user who is privileged to work with dtrace commands
  • Determine the process id (pid) for the application server (GlassFish v3) using jps -l
    munnangi[212]: jps -l
    1978 com.sun.enterprise.glassfish.bootstrap.ASMain
    2513 sun.tools.jps.Jps
  • Download and start the gfv3_web_ejb.d script using ./gfv3_web_ejb.d 1978
  • Now using browser, access the application http://localhost:8080/converter
  • You'll see the following output in dtrace terminal showing the time taken by each module.
    munnangi[213]: ./gfv3_web_ejb.d 1978
    dtrace: script './gfv3_web_ejb.d' matched 6 probes
    CPU ID FUNCTION:NAME
    1 1 :BEGIN Collecting data, press \^c to end...

    1 76185 http-service:requestStartEvent requestStartEvent
    1 76723 bean:containerEnteringEvent time taken in micro sec. = 923
    1 76724 bean:containerLeavingEvent time taken in micro sec. = 1700
    1 76723 bean:containerEnteringEvent time taken in micro sec. = 188
    1 76724 bean:containerLeavingEvent time taken in micro sec. = 1263
    1 76184 http-service:requestEndEvent time taken in micro sec. = 4364
  • From the above one can easily how much time is spent in each module.
Refer to Sun GlassFish Enterprise Manager DTrace Monitoring 3.0 Beta Installation and Quick Start Guide  for detailed instructions.

Wednesday Dec 09, 2009

Java EE 6 Samples for GlassFish Project

Java EE 6 Technologies offer many innovatiove and develoepr friendly features. Revolving around right sizing the features include extensibility, ease of development, ejb lite, dependency injection and many more.

To illustrate some of the above technologies, Java EE 6 samples have been developed as part of glassfish-samples project. These samples are available as part of Java EE 6 SDK. For distributions other than SDK, the samples can be downloaded ind installed. The instructions for installing and running the samples are very simple.

To give a flavor, the sample applications demonstrate Java EE 6 features like embedding ejb in a war, asynchronous servlet API, web fragments, annotate a web service with @Singleton, injecton of Web Service Client by the container, no-interface EJB session beans as RESTful resource classes, annotate REST resource class with ManagedBean annotation, illustrate some of the new Ajax features that are contained in JSF 2.0, use of Weld with JSF 2.0, programmatic security , annotations introduced in Java EE Connector Architecture, locking with Java Persistence APIs, and more.

As always your feedback is welcome at users@glassfish-samples.dev.java.net

Monitoring in GlassFih v3 - It's Different and Cool!

It is different from previous version as it has become light by using light weight probe based architecture. This enables us to perform ad hoc monitoring in production with minimal impact. One does not have to restart the server, just start monitoring the specific issue at hand, very similar to DTrace on Solaris. In fact, GlassFish v3 monitoring exposes monitoring probes as DTrace probes on Solaris and Mac.This combined with native dtrace probes of Solaris provide an opportunity to monitor attributes which was not possible earlier. Don't worry, for non-solaris platforms, we have client-scripting. Determine the probes you want to monitor and write a java script using these probes, deploy the script to server and start receiving monitoring events. Isn't that Cool!

Friday Sep 11, 2009

How to create pluggable container-monitoring element in GlassFish v3

For new modules like JRuby which can be added at runtime, it is possible to use v3 monitoring config using pluggability as given in the sample code below.
import org.glassfish.internal.api.Init;
import org.jvnet.hk2.annotations.Service;
import org.jvnet.hk2.component.PostConstruct;
import org.jvnet.hk2.annotations.Inject;
import org.glassfish.api.Startup;
import com.sun.enterprise.config.serverbeans.MonitoringService;
import org.jvnet.hk2.config.SingleConfigCode;
import org.jvnet.hk2.config.ConfigSupport;
import org.glassfish.api.monitoring.ContainerMonitoring;
import org.jvnet.hk2.config.TransactionFailure;
import java.beans.PropertyVetoException;

@Service
public class AddonInit implements PostConstruct {

    @Inject
    MonitoringService ms;

    public void postConstruct() {
        mprint("addon init postConstruct() ...");
        if (ms.getContainerMonitoring("jruby") == null) {
            try {
                ConfigSupport.apply(new SingleConfigCode<MonitoringService>() {
                    public Object run(MonitoringService param)
                    throws PropertyVetoException, TransactionFailure {
                        ContainerMonitoring newItem = param.createChild(ContainerMonitoring.class);
                        newItem.setName("jruby");
                        newItem.setLevel("HIGH");
                        param.getContainerMonitoring().add(newItem);
                        return newItem;
                    }
                }, ms);
            } catch (TransactionFailure tf) {
                // log warning
                // handle exception
            }
        }
    }

    private void mprint(String str) {
        if (debug) {
            System.out.println("... MSR: " + str);
        }
    }

    private final boolean debug = true;
}

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 May 07, 2008

Apache to front end a set of IPS repository daemons

To allow reverse proxying, so that apache could front end the pkg.depotd daemons, perform the following:
  • Enable the following modules in <apache-install>/etc/httpd.conf.

    LoadModule proxy_module libexec/mod_proxy.so LoadModule proxy_http_module libexec/mod_proxy_http.so

  • Add proxy entries to <apache-install>/etc/httpd.conf corresponding to the pkg.depotd ports.

    # Reverse Proxy Setup
    ProxyRequests off
    # sparc
    ProxyPass /dev/solaris-sparc/gf3000_2000/ http://localhost:10000/
    ProxyPassReverse /dev/solaris-sparc/gf3000_2000/ http://localhost:10000/
    # linux
    ProxyPass /dev/linux/gf3000_2000/ http://localhost:10001/
    ProxyPassReverse /dev/linux/gf3000_2000/ http://localhost:10001/
    # mac
    ProxyPass /dev/mac/gf3000_2000/ http://localhost:10002/
    ProxyPassReverse /dev/mac/gf3000_2000/ http://localhost:10002/
    # solaris x86
    ProxyPass /dev/solaris-x86/gf3000_2000/ http://localhost:10003/
    ProxyPassReverse /dev/solaris-x86/gf3000_2000/ http://localhost:10003/
    # windows
    ProxyPass /dev/windows/gf3000_2000/ http://localhost:10004/
    ProxyPassReverse /dev/windows/gf3000_2000/ http://localhost:10004/
    # default
    ProxyPass / http://localhost:10000/
    ProxyPassReverse / http://localhost:10000/
    
  • Change the custom log to combined format.

    Comment the following line

    # CustomLog var/log/access_log common
    

    Uncomment the following line

    CustomLog var/log/access_log combined
    

The apache httpd can be setup as Solaris SMF service so that the process is monitored by SMF. Here are the steps:

  • Create service manifest /var/svc/manifest/application/apache2/httpd.xml. Replace the location of apache httpd script appropriately.

    Download httpd.xml

  • Validate and import the service manifest using svccfg(1M).

    bash-3.00# svccfg
    svc:> validate /var/svc/manifest/application/apache2/httpd.xml
    svc:> import /var/svc/manifest/application/apache2/httpd.xml
    svc:> quit
    
  • Enable the service using the svcadm command.

    svcadm enable -t svc:/application/apache2/httpd

  • Verify that the service is online.

    bash-3.00# svcs -a | grep -i apache online May_02 svc:/application/apache2/httpd:default

Saturday Jan 19, 2008

Try GlassFish for a chance to win an iPhone

GlassFish V2 UR1 provides all of the stability and capabilities of the V2 release, plus many new improvements of which one is support for the AIX platform. Please refer to the GlassFish V2 Update Release Wiki Page for details on improvements that are going into this release.

Apart from support through Forums, Mailing Lists it provides continuous and very useful blogs through Aquarium.

When you download and register this enterprise strength Java EE Server, you also get a chance to win an iPhone. Please refer to the promotion Try GlassFish for a chance to win an iPhone for more details.

Wednesday Dec 05, 2007

Runtime Management of Sailfin Applications

The JSR77 spec. provides server vendors with a standard model for managing the Java EE Platform.

GlassFish V2/Sun Java System Application Server 9.x provides the default JSR77 implementation. Based on this, after deploying an application it is possible to start/stop the application using its runtime management mBean. However if the application is deployed in disabled state then no mBean is created for its runtime management.

A version of application server is being developed for Sailfin based on the GlassFish V2 source. Sailfin applications are deployed using extended archive version of 'SAR' and the implementation requires that even if the application is disabled, its runtime management mBean need to be available to perform start/stop operations. Accordingly the code has been added to provide this feature. Now it is possible to manage Sailfin application like a standard Java EE application, more importantly, start/stop the applications even if they are disabled. The start/stop operations can be performed using any standard jmx console, for ex. jconsole which comes with jdk 6.0 or any JMX compatible Console. One can use the connection parameters from the Application Server log. The jmx connector URL is printed in the server.log when the Application Server is started.

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

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