Hi JB, it turns out this is most likely the old Issue I reported once. Having now more insights into what should be done, I propose this solution: https://github.com/apache/karaf/pull/138
It basically ensures that only one provision is concurrently executing. What do you think? Fabian On Tue, Jan 26, 2016 at 10:19 PM, Fabian Lange <fabian.la...@codecentric.de> wrote: > Hi JB, > not really reproducable. We had this before, and I then introduced a > locking abstraction around the features manager. This is a programmatic > installation of features. So I assume that features are no longer installed > concurrently. > > However it might race with karaf/felix bootstrap and feature installation. > I only synchronized my installation > > What I do, is that I add a feature repository, then do a foreach and add > the requirements, then fire off the install > > Fabian > > > On Tue, Jan 26, 2016 at 10:16 PM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> It sounds like concurrent update of feature state in the store. >> >> Does it mean users install/uninstall multiple features in the same time ? >> >> Any use case to reproduce it ? >> >> Thanks >> Regards >> JB >> >> >> On 01/26/2016 09:18 PM, Fabian Lange wrote: >> >>> Hi all, >>> I am seeing a significant amount of following stacktraces reported by our >>> users. they seem to go away with restarting, so it looks like a leak or >>> race condition to me: >>> >>> java.lang.NullPointerException >>> >>> at >>> java.io.FileOutputStream.<init>(FileOutputStream.java:203)[:1.8.0_72] >>> >>> at >>> java.io.FileOutputStream.<init>(FileOutputStream.java:162)[:1.8.0_72] >>> >>> at >>> org.apache.karaf.features.internal.osgi.Activator$1.getOutputStream(Activator.java:197)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.StateStorage.save(StateStorage.java:56)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:297)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:1154)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:764)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[7:org.apache.karaf.features.core:4.0.4] >>> >>> at >>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72] >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72] >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72] >>> >>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_72] >>> >>> >>> the NPE is caused by bundleContex.getDataFile(state.json) returning null. >>> The javadoc says that this could be possible, but because it works most >>> of >>> the time I speculate this might be actally a race condition, or maybe >>> leaked filehandles somewhere. >>> Anybody got pointers or ideas? >>> I am willing to make a fix, but I need to understand this more >>> >>> Fabian >>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
