Sounds like you've hit some bugs. :-) 1) Dynamic-Import probably does need updating for this. dstributions/bundle/all/pom.xml Have at it. :-)
2) Might be related to 3. If the mbeans aren't unregistered, maybe the name is taken or something and they cannot be re-registered. 3) Looking at the code, nowhere (other than in the tests and shutdown of the InstrumentationManager) do we call the InstrumentationManager.unregister methods. Thus, we definitely need to add code to unregister the beans. Dan On Tuesday 23 March 2010 1:37:56 pm David Valeri wrote: > 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/t > o 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! -- Daniel Kulp [email protected] http://dankulp.com/blog
