The problem here is that file install cannot dictate the framework what to refresh. The refresh method takes an initial set of bundles, but the framework calculates a "dependency closure" (see 7.6.1 of the spec for example). If that closure includes file install, then this issue occurs. The only way file install can solve this is by making sure it never gets included by not importing anything or by modifying the code so it does not deadlock. I think that modifying the code is the best option, because that ensures that this can never happen. Any other solution is probably very fragile as *any* bundle can trigger a refresh that might include file install.
Greetings, Marcel On 29 Apr 2014, at 21:22 pm, Raymond Auge <[email protected]> wrote: > I don't think fileinstall should ever really be able to refresh itself > exactly for the reason that it's going to create a deadlock. > > It would appear to me that fileinstall should just ignore anything that it > can't itself manage, such as itself. > > I'm actually wondering why > > felix.fileinstall.optionalImportRefreshScope=managed > > isn't the default > > The default is null which equates to all framework bundles which seems is > leading to the problem. > > - Ray > > > On Tue, Apr 29, 2014 at 3:14 PM, Guillaume Nodet <[email protected]> wrote: > >> My question was about why fileinstall refreshes itself. It must be because >> you deploy either configadmin or a log service as those are the only two >> optional imports on fileinstall. >> >> >> 2014-04-29 20:53 GMT+02:00 Raymond Auge <[email protected]>: >> >>> I'm not using config admin at all. Rather, the only path to setting the >> bit >>> I need is via service update lifecycle. >>> >>> - Ray >>> >>> >>> On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <[email protected]> >>> wrote: >>> >>>> Are you trying to use fileinstall to deploy configadmin ? >>>> That's not really supported, but it should not be very difficult to >>>> support. >>>> Please raise a JIRA. >>>> >>>> I think allowing all configuration bits to be available from the bundle >>>> context would be a good work around. >>>> >>>> >>>> 2014-04-29 20:13 GMT+02:00 Raymond Auge <[email protected]>: >>>> >>>>> It would seem that this could be solved it it were possible to pass >> the >>>>> property: >>>>> >>>>> felix.fileinstall.optionalImportRefreshScope=managed >>>>> >>>>> but this property cannot be passed except via config admin, so you >>> can't >>>>> bootstrap the system as it is. >>>>> >>>>> - Ray >>>>> >>>>> >>>>> On Tue, Apr 29, 2014 at 1:28 PM, Raymond Auge < >>> [email protected] >>>>>> wrote: >>>>> >>>>>> Hey All (cross posted as I'm not sure where the answer will come >>> from), >>>>>> >>>>>> versions: >>>>>> - fileinstall 3.4.0 >>>>>> - equinox 3.8.0.v20120529-1548 >>>>>> >>>>>> I'm seeing a deadlock where on first start the fileinstall bundle >> is >>>>>> getting stuck with itself >>>>>> >>>>>> as per the following two stack traces: >>>>>> >>>>>> "Refresh Packages" daemon prio=10 tid=0x00007fc29c0f6800 nid=0x94c >>>>> waiting on condition [0x00007fc2b9c15000] >>>>>> java.lang.Thread.State: WAITING (parking) >>>>>> at sun.misc.Unsafe.park(Native Method) >>>>>> - parking to wait for <0x00000000c095f950> (a >>>>> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) >>>>>> at >>>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251) >>>>>> - locked <0x00000000c0cbc1f8> (a >>>>> org.eclipse.osgi.framework.internal.core.PackageAdminImpl) >>>>>> at >>>>> >>>> >>> >> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) >>>>>> at java.lang.Thread.run(Thread.java:744) >>>>>> Locked ownable synchronizers: >>>>>> - None >>>>>> >>>>>> >>>>>> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon >>> prio=10 >>>>> tid=0x00007fc2ac01a000 nid=0x920 waiting on condition >>>> [0x00007fc2ba721000] >>>>>> java.lang.Thread.State: WAITING (parking) >>>>>> at sun.misc.Unsafe.park(Native Method) >>>>>> - parking to wait for <0x00000000c51bd048> (a >>>>> java.util.concurrent.CountDownLatch$Sync) >>>>>> at >>>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) >>>>>> at >>>>> >>>> >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) >>>>>> at >>>>> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358) >>>>>> at >>>>> >>>> >>> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310) >>>>>> Locked ownable synchronizers: >>>>>> - None >>>>>> >>>>>> You can see that the refresh event will never return (to tear down >>> the >>>>>> latch) as long as the FileInstall.stop operation can't get the lock >>> in >>>> to >>>>>> directory which it's currently holding during the refresh >> operation! >>>>>> What seems strange is that fileinstall is adding itself to the list >>> of >>>>>> bundles to refresh during the >>>>>> findBundlesWithOptionalPackagesToRefresh(toRefresh); call. Is that >>>>> expected? >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> -- >>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>> (@rotty3000) >>>>>> Senior Software Architect >>>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>> (@rotty3000) >>>>> Senior Software Architect >>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>>>> >>>> >>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect >>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay) >>> >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
