Hello Nima, It would be interesting and nice to have some service available at the container level to monitor the resources of a bundle as well as its interactions more generally. I know I would like to use some stuff like this.
But I have to agree it is hard to do without the ThreadPool approach. You need some means to associate the executed code and the used resources to the correct bundle. The ThreadPool seems to give you this. Do you have some idea of the overhead it has as this seems to concern you? It does not sound like it would be a big overhead. It also seems like a lot of work to implement all the required functionality for effective monitoring, such as proxy creations, modifications of the container for the ThreadPool, instrumenting all object creation, etc. So it would be nice to have this stuff implemented as services that could be used as is, without need to redo many times. But I have no idea how to try to get this into some OSGI spec. Maybe if you implement something, you could provide it for the Felix implementation as a first step? Given some time constraints, maybe you could also get some contributions from others.. :) Teemu 2010/2/27 Nima Kaviani <[email protected]> > Hello all, > > @Pierre, thanks for pointing out JVisualVM. It looks like an excellent > tool, > but it doesn't expose any API that I can use in order to programmatically > monitor the behavior of OSGi bundles or do some further analysis on the > collected data. > > Since Cliff and Ali also showed some interest in this topic, I thought I > would discuss the results of my search for the past couple of days here to > also benefit from your bright minds and come up with some solutions on how > bundle profiling could be implemented for a SPEC 4.2 compliant OSGi > framework. > > I examined some of the most up to date profiling tools, namely, JProfiler, > JProbe, JVisualVM, JPI, JRockit Mission Control, and YourKit. The first > three are proprietary and do not expose any API. JRockit Mission Control is > free and has some sort of an API that could be used for profiling, but it > only works with JRMC and when I ran felix against it, it drastically slowed > down the performance of my application. JPI profiling results would only > give me information on org.osgi.framework classes and nothing else! Not > sure > if this is because of having several class loaders for different bundles or > whether there is something else confusing JPI. YourKit is apparently the > only one which comes with an API but it does not provide monitoring at a > level as fine-grained as JVisualVM (as Pierre said one can monitor > processes > in JVisualVM at the level of methods, classes, or packages, making possibly > to cherry pick the classes or packages and associate them with bundles). > > I think what I am going to do is to write a bundle that would incorporate > YourKit's API so that I can examine how closely I can resemble the behavior > of a target bundle by monitoring its behavior as a matter of combining > collected information from YourKit and information received from the > BundleContext. So it would be like, inspecting the internal of a bundle by > reflection and then matching them against the results of thread stack trace > from the profiler. Do you guys have any better suggestion? > > @Cliff, I agree that thread pooling per bundle is an expensive task > (specially with what YourKit offers, I have to inspect the thread stack > trace in order to pool out the information that I require), but I couldn't > think of any other way that would allow me to establish the associations > between a process and its source bundle. so, I couldn't think of any > alternative to what was suggested in the masters thesis I referenced > earlier > in this thread. Do you have a better idea? I mean, even if there is going > to > be a Profiling RFC for the next OSGi Spec, what could it be (considering > what JMX offers)? I am asking cause I might be able to somehow try it in my > code and get some hints about how it may work. > > thanks guys and sorry for the long email. your thoughts and suggestions on > this matter are very much appreciated of course. > > -Nima > > > On Fri, Feb 19, 2010 at 8:48 AM, Ali Naddaf <[email protected]> wrote: > > > I am also interested in knowing what one can do there. I have read that > J9 > > has some extensions that enables a granular control of resources (memory, > > CPU) at the bundle level and ProSyst folks have some management tools > around > > that but that is the only JRE that I have heard whcih has that kind of > > capability, and of course that is not a universal feature of JREs so > won't > > help most people. > > > > > > On 2/19/2010 10:40 AM, Clifford H. James wrote: > > > >> I had wondered the same thing and at the time of my search all I found > was > >> that thesis project that you mentioned below. Let me know if you find > >> anything because this is an area that I think needs some attention > (perhaps > >> from the OSGi Alliance people in an upcoming spec?) but I'm not sure if > the > >> "ThreadPool per bundle" that the author took doesn't create more > troubles > >> than it's worth -- it certainly isn't an unintrusive way to monitor > bundle > >> resource consumption. > >> > >> ~Cliff > >> > >> Nima Kaviani wrote: > >> > >>> Hi all, > >>> > >>> I wonder if anybody knows of any profiling library / API that would > allow > >>> me > >>> to monitor the CPU and memory usages at a bundle level of granularity? > >>> > >>> I have already looked into JProfiler, but there are two problems with > >>> JProfiler. It is not a free tool, and also its profiling happens the > >>> level > >>> of objects and packages (the second issue could have been resolved if I > >>> could play around with the source code of course). I also found this > >>> thesis > >>> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf) which takes a > >>> rather > >>> intrusive approach in modifying the internals of an osgi framework in > >>> order > >>> to support resource monitoring and profiling. Any help along this line > is > >>> very much appreciated. > >>> > >>> thanks, > >>> -Nima > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > http://nima.magic.ubc.ca >
