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)
