Table of Contents
The ability to provide data of how an application is being used at runtime is an important feature offered by many frameworks. Grizzly 2.2.10 is no exception. Grizzly provides the ability to monitor key components within the framework and allows this monitoring to be extended by custom authored components. Let's start by looking at the entities that enable monitoring within Grizzly.
At the core of Grizzly monitoring are three simple artifacts in the org.glassfish.grizzly.monitoring package. The first being called MonitoringAware which denotes an entity may be monitored:
1 /** 2 * General interface for the objects, which could be monitored during the lifecycle. 3 * 4 * @author Alexey Stashok 5 */ 6 public interface MonitoringAware<E> { 7 /** 8 * Return the object associated {@link MonitoringConfig}. 9 * 10 * @return the object associated {@link MonitoringConfig}. 11 */ 12 MonitoringConfig<E> getMonitoringConfig(); 13 }
Entities such a MemoryManager, Transport, etc are all MonitoringAware. As seen by the interface definition, all MonitoringAware entities return a MonitoringConfig object with which you can register monitoring probes.
1 /** 2 * General monitoring configuration interface. 3 * 4 * @author Alexey Stashok 5 */ 6 public interface MonitoringConfig<E> { 7 /** 8 * Add the monitoring probes, which will be notified about object's lifecycle events. 9 * 10 * @param probes the monitoring probes. 11 */ 12 public void addProbes(E... probes); 13 14 /** 15 * Remove the monitoring probes. 16 * 17 * @param probes the monitoring probes. 18 */ 19 public boolean removeProbes(E... probes); 20 21 /** 22 * Get the the monitoring probes, which are registered on the objet. 23 * Please note, it's not appropriate to modify the returned array's content. 24 * Please use {@link #addProbes(Object[])} and 25 * {@link #removeProbes(Object[])} instead. 26 * 27 * @return the the monitoring probes, which are registered on the object. 28 */ 29 public E[] getProbes(); 30 31 /** 32 * Removes all the monitoring probes, which are registered on the object. 33 */ 34 public void clearProbes(); 35 } 36
Since MonitoringConfig is really nothing more than a simplified collection, Grizzly provides a default implementation called org.glassfish.grizzly.monitoring.MonitoringConfigImpl. This should be able to satisfied most developer needs.
Monitoring probes, as seen in the code example above, can be of any type. Grizzly provides probe interfaces for all MonitoringAware entites within the framework.
Table 11.1. Core Module Probes
org.glassfish.grizzly.TransportProbe | Provides details on events happening within a particular Transport. Such events include when the transport is started, stopped, an error occurring, or if the transport's configuration has been changed. |
org.glassfish.grizzly.ConnectionProbe | Provides details on Connections within the framework. This includes both binding of server-side sockets, or inbound connections from clients. |
org.glassfish.grizzly.memory.MemoryProbe | Provides buffer allocation (both pooled and non-pooled)/deallocation events. |
org.glassfish.grizzly.threadpool.ThreadPoolProbe | Provides details relating to the lifecycle of the threadpool itself as well as that of the threads it manages as well as delegated task information. |
Table 11.2. Http Module Probes
org.glassfish.grizzly.http.HttpProbe | Provides details related to the HTTP codec processing itself. Details such as the parsing headers, content chunks, as well as the reverse when content is serialized to the wire. |
org.glassfish.grizzly.http.KeepAliveProbe | Provides details pertaining to HTTP keep-alive statistics. |
Table 11.3. Http Server Module Probes
org.glassfish.grizzly.http.server.HttpServerProbe | Provides details relating to request processing lifecycles, such as request started, completed, suspended, timed-out, or cancelled. |
org.glassfish.grizzly.http.server.filecache.FileCacheProbe | Provides file cache statistics such as a entry being cached, removed from the cache, and cache hits/misses. |