felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: deadlock in fileinstall on equinox
Date Tue, 29 Apr 2014 19:14:24 GMT
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 <raymond.auge@liferay.com>:

> 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 <gnodet@apache.org>
> 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 <raymond.auge@liferay.com>:
> >
> > > 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 <
> raymond.auge@liferay.com
> > > >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)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message