Hello Nima, If you intend to work on this, I am interest to collaborate with whatever I can help. I agree the optimal case would be to have a completely independent module. However, I fear implementing it in an effective way would be difficult. That should not stop us from trying of course. Do you have some ideas you wish to share?
I would personally be interested in monitoring different aspects of the OSGI bundles/services, starting with all their interactions and bundle/service resource consumptions. Maybe you already know of some way to monitor interactions between different services (invocations to any service) without proxies? For the resource consumption one major issue for me is that I don't know of a generic way to get resource consumption information breakdown information from a JVM, and if I could, then I would not know how to map each resource used to bundles/services without something like the threadpool solution. Teemu 2010/3/2 Nima Kaviani <[email protected]> > Hello all, > > I was holding on the reply for a bit to get some more input on this topic. > > Thanks Marcel for the link to I-JVM. There were interesting ideas discussed > in the paper, however it still seems to me that they somehow impose > constraints on using threads for Bundles and the OSGi container (Page 5) > which again emphasizes the need to monitor or isolate bundle behaviors > using > thread pools. On a separate note, I am mainly looking for an approach that > makes as minimal change as possible to the existing JVM or OSGi > architecture. Unless there is going to be a standard for defining a clear > cut border between bundles at the level of JVM or OSGi container, making > assumptions on how a JVM or OSGi container should work to support > monitoring > does not work in my case. Yet, as you also said, some of their ideas might > be applicable to bundles without having to modify the internals of a JVM or > OSGi container. > > Teemu, I would highly appreciate the help from anyone who would like to > collaborate or brainstorm on developing a monitoring module for OSGi > bundles. I think it probably is better to see how close we can get to a > proper monitoring module without having to modify the internal of an OSGi > container to extend it with proxy bundles or using thread pools. > > -Nima > > On Sat, Feb 27, 2010 at 10:01 AM, teemu kanstren <[email protected] > >wrote: > > > 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 > > > > > > > > > -- > http://nima.magic.ubc.ca >
