Re: Isolation of OSGI resources and lock problems

2009-03-17 Thread Richard S. Hall
On 3/17/09 3:59 PM, João Ferreira wrote: Hello again I managed to do the isolation i pretended. The lock that was acquired was a BundleImpl lock that was associated with the thread that owned the lock. I just swaped that thread reference with my thread, waited for my thread to stop and swaped

Re: Isolation of OSGI resources and lock problems

2009-03-17 Thread João Ferreira
Hello again I managed to do the isolation i pretended. The lock that was acquired was a BundleImpl lock that was associated with the thread that owned the lock. I just swaped that thread reference with my thread, waited for my thread to stop and swaped the thread reference back to the old thr

RE: Isolation of OSGI resources and lock problems

2009-03-15 Thread Kiev Gama
1462803 [2]http://www.jraf2.org/ [3]http://www.inf.unisi.ch/projects/ferrari/FERRARI.html > Date: Sat, 14 Mar 2009 22:03:42 + > From: jtjeferre...@gmail.com > To: users@felix.apache.org > Subject: Re: Isolation of OSGI resources and lock problems > > Hi > > I already r

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread João Ferreira
Hi I already read about VM kit in this paper [1], but its more focused in security for a JVM and they do heavy modification in the VM. I think i can resolve my problem with Felix modifications and a bit of JVM TI[2] using. For what i have understand of the code i think its possible to do what i wa

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread Marcel Offermans
On Mar 14, 2009, at 22:22 , Stevens Gestin wrote: For my OSGI bundles development I choose to make bundles as independent as possible on other bundles. In this approach, I'm not sharing libraries like logging, SAX, etc. and each bundle uses its own library set. Is this a bad concept? No,

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread Stevens Gestin
VMKit is a very interresting project. Thanks. For my OSGI bundles development I choose to make bundles as independent as possible on other bundles. In this approach, I'm not sharing libraries like logging, SAX, etc. and each bundle uses its own library set. Is this a bad concept? Stevens On Sat,

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread Marcel Offermans
Hello João, After reading what you're trying to do, I immediately had to think about some research I learned about when attending FOSDEM'09 recently. It's called VMKit, and based on it, they are doing research into using a new isolation abstraction for OSGi. References: http://vmkit.llvm

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread Richard S. Hall
My tip is essentially to just try to start your thread before the calling thread gets the locks in question. If that is not possible, you will have to look at which locks it acquires. If they are part of the locking protocol implemented by Felix, then you might be able to modify them to make t

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread João Ferreira
Hi Yes Im using trunk code. I got this idea from this previous work [1] but unfortunately the code is not available. Im not sure i understand your tips, because im not very familiar with the code and what the start level is supposed to do. What i need is that the start() method of the bundle is

Re: Isolation of OSGI resources and lock problems

2009-03-14 Thread Richard S. Hall
I am not sure what you want to do is possible. At a minimum, you would have to do your hand off before the start level thread acquires the locks. If the start level thread is only acquiring lock objects, you could potentially modify them to make them transferable to another thread, but this wo

Isolation of OSGI resources and lock problems

2009-03-14 Thread João Ferreira
Hi I'm doing some work in OSGi in an attempt to add better resource monitoring to osgi applications. My objective is to isolate the cpu consumption across the different bundles. To implement this my strategy is to group the different threads in ThreadGroups, where there is a different ThreadG