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.

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