I don't see anything in the framework that is holding this up. We must
stop the bundles that are involved in a refresh and the deadlock is
contained in file install itself. Could you remove the optional imports
from file install to see if it helps to avoid it getting pulled into the
refresh operation? Perhaps they should be dynamic imports to avoid the
need for static optional ones? This way the file install bundle would not
need refreshed when the "optional" packages become available (not that I
like to advocate dynamic imports).
Tom
From: Raymond Auge <raymond.a...@liferay.com>
To: Apache Felix Developers <d...@felix.apache.org>, Equinox
development mailing list <equinox-dev@eclipse.org>
Date: 04/29/2014 01:14 PM
Subject: Re: [equinox-dev] deadlock in fileinstall on equinox
Sent by: equinox-dev-boun...@eclipse.org
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.a...@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é (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
