Thank you to everyone who provided some insight around the available metrics. I've got a couple issues/quirks I want to resolve in the work that I am doing.
I had things working reasonably well when I was using the jaxws frontend namespace handler based configuration and starting my service endpoints during the bootstrapping of my bundle using Spring DM. In this case, CXF started Jetty during the creation of the ApplicationContext and was able to also provide the configured MBeanServer to Jetty. When I delayed the instantiation of the service endpoints by performing the publishing programmatically as triggered by Spring DMs configuration update facilities, I am running into some issues with the dynamic loading of the Jetty management classes. When Spring DM's bundle extender publishes the services during ApplicationContext startup, the Thread Context Class Loader (TCCL) is tied to my bundle and is able to find org.mortbay.management.MBeanContainer (from JettyHTTPServerEngine#addServant). When the service publishing is triggered by Spring's configuration update thread, the TCCL is Equinox's ContextFinder (at least in my environment) and org.mortbay.management.MBeanContainer cannot be resolved. After stepping through the code, the ContextFinder does resolve the CXF bundle's ClassLoader and dutifully searches for the class. It would appear that the CXF bundle doesn't import org.mortbay.management in either an Import-Package or DynamicImport-Package manifest header. The felix-bundle-plugin is configured with org.mortbay*;resolution:=optional. Does the bundle need more imports/dynamic imports to sort this out or am I missing something simple? The second issue I am encountering is the disappearance of registered MBeans when I restart my bundle. Everything starts back up, but the CXF MBeans are not registered again. I haven't hunted this one down yet. Has anyone else come across this behavior? The third issue I am encountering has to do with stopping an EndpointImpl from the JAX-WS FrontEnd. When I trigger the stop programmatically, the endpoint is removed and the service is no longer accessible. However, the MBean is not unregistered by ServerImpl (ServerImpl does the registering when the Endpoint is started). In JConsole, I can restart the EndpointImpl and it would appear that strong references are maintained to the EndpointImpl and consequently to its implementor Object. I would like to effectively destroy the EndpointImpl such that its MBean is unregistered and it will be garbage collected down the road. Is there a facility to do this or would I need to unregister the MBean manually after I stop the EndpointImpl? I don't see any lifecycle listeners on the EndpointImpl. Aside from the MBean, is there anything else that would need to be cleaned up to allow garbage collection of the EndpointImpl and the other unused resources that it references? -----Original Message----- From: Cyrille Le Clerc [mailto:[email protected]] Sent: Saturday, March 13, 2010 6:58 AM To: [email protected] Subject: Re: CXF JMX Metrics Hello David, Here is a web page that summarizes all the CXF response time of one cluster node of a live application I work on. It will show you real data. That are all the informations we need. This JSP page (cxf.jsp) is just used for troubleshooting ; we use Hyperic for monitoring with the attached plugin (cxf-plugin.xml). Hyperic plugin for CXF : http://xebia-france.googlecode.com/svn/jmx/jmx-demo/trunk/src/main/hyperic/c xf-plugin.xml CXF JMX metrics page : http://xebia-france.googlecode.com/svn/jmx/jmx-demo/trunk/src/main/webapp/to ols/jmx/cxf.jsp Hope this helps, Cyrille -- Cyrille Le Clerc [email protected] On Fri, Mar 12, 2010 at 7:42 PM, David Valeri <[email protected]> wrote: > I've got CXF running in an OSGi container and managing its own Jetty instance rather than using the container's HTTP service. I have JMX enabled on CXF per the instructions in the documentation. > > I'm seeing the following MBeans in JConsole: > > org.apache.cxf.Bus > org.apache.cxf.Bus.Service.Endpoint > org.apache.cxf.WorkQueueManager > org.apache.cxf.transport.http_jetty.jettyhttphandler > > I'm not seeing a bean for CXFJettySslSocketConnector because I am deploying a custom connector and the bean is being registered by Jetty based on my custom class name. > > In these beans, I am not seeing much that is indicative of the runtime health of the services running in CXF. The Jetty connector and the optional statistics handler, which I have enabled, collect performance metrics that can be used to gauge the overall health of all services running on a particular port and the CXF metrics allow one to gauge if the services started appropriately. > > The docs mention a CounterRepository that stores max response time. Is there anything else in CXF worth monitoring that can indicate runtime health? > > Thank you in advance for any help! >
