Grizzly 2.0 now has JMX support.

So, it's been some time since I've last blogged.  Several changes have occurred since then.  One of these changes is my move from the Mojarra to the Grizzly project.

The team has been hard at work getting Grizzly 2.0 into shape, and it's coming along nicely.  The latest feature we've added is support for JMX monitoring.

Enabling JMX Support

Grizzly 2.0 JMX support is enabled through another related project called "gmbal" (pronounced "gumball").  This project allowed us to take the grunt work out of working with JMX via JDK5 annotations.   If a project has JMX requirements, it simply needs to add a maven dependency with the group id of org.glassfish.gmbal and artifact id gmbal.

Once the dependency has been included in the project, it's very simple to enable monitoring:

Giving the JMX Monitoring a Test Drive

Using the code snippet above, with the server running, connect to the server using JConsole:

Select the process of your java application and click Connect.  Once connected, select the MBeans tab and expand the com.sun.grizzly root.

So, what do these MBeans represent?

  • The DefaultMemoryManager provides details on the memory managed subsystem introduced in Grizzly 2.0.  There will be one DefaultMemoryManager per Transport.
  • FileCache provides details on the static file caching mechanism that may be enabled on a per-Transport basis.
  • GrizzlyListener is an abstraction around the Grizzly 2.0 Transport.  This provides details on the listener configuration (i.e., port, network host, secure, etc.).
  • GrizzWebServer is the root of the JMX hierarchy.
  • HttpCodecFilter monitors statistics related to HTTP protocol parsing/encoding.
  • TCPNIOTransport is the concrete Transport implementation used by a GrizzlyListener.  There will be one transport per GrizzlyListener instance.
  • ThreadPool provides details on the threads being used by the GrizzlyWebServer.  Note that this pool is shared by all Transports, however, JConsole
    may show more than one thread pool as being available.
  • WebServerFilter provides details on the higher level HTTP server processing (i.e., how many requests have been serviced, how may responses
    are current suspended, etc.)

I've included some examples of some of the monitoring statistics that are available after making several requests to the server:

ThreadPool

HTTP Codec Filter

Web Server Filter

Memory Manager

If anyone decides to give this a shot and and has ideas to offer on improving monitoring support or if you find a problem, please feel free to log a request on the project issue tracker, or join the user mailing list and start a discussion with your ideas. 

    Comments:

    Hey Ryan,
    Sorry to hear you left the Mojarra team. Care to divulge why you did? You seemed to be one of the driving forces behind it, along with Ed Burns.
    Regards,
    Maarten

    Posted by Maarten on August 12, 2010 at 08:06 PM PDT #

    @Maarten :

    I've been working on JSF in some capacity since before the final release
    of JSF 1.0. It was time for a change. However, that said, Mojarra is
    in good hands. Ed, Roger, and Sheetal are working diligently on the
    implementation.

    Posted by Ryan Lubke on August 13, 2010 at 08:17 AM PDT #

    Good to hear!
    Best of luck on the Grizzly team. I've been using it recently as an embedded servlet contianer to test my Jersey classes, and it's remarkably fast.

    Posted by Maarten on August 13, 2010 at 08:20 AM PDT #

    Post a Comment:
    Comments are closed for this entry.
    About

    user12615560

    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