Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Fri, 27 Mar 2015 08:50:53 +0000 (UTC)
From: "David Bosschaert (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12711286.1398798444000.47846.1427446253540@Atlassian.JIRA>
In-Reply-To: <JIRA.12711286.1398798444000@Atlassian.JIRA>
References: <JIRA.12711286.1398798444000@Atlassian.JIRA>
 <JIRA.12711286.1398798444113@arcas>
Subject: [jira] [Resolved] (FELIX-4501) Impossible to set the
 felix.fileinstall.optionalImportRefreshScope property from startup
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/FELIX-4501?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Bosschaert resolved FELIX-4501.
-------------------------------------
    Resolution: Fixed

Thanks [~rotty3000]! I've committed your fix in http://svn.apache.org/viewv=
c?view=3Drevision&revision=3D1669527

> Impossible to set the felix.fileinstall.optionalImportRefreshScope proper=
ty from startup
> -------------------------------------------------------------------------=
---------------
>
>                 Key: FELIX-4501
>                 URL: https://issues.apache.org/jira/browse/FELIX-4501
>             Project: Felix
>          Issue Type: Bug
>          Components: File Install
>    Affects Versions: fileinstall-3.4.0
>         Environment: confirmed on equinox 3.8.0.v20120529-1548
>            Reporter: Raymond Aug=C3=A9
>            Assignee: David Bosschaert
>            Priority: Minor
>         Attachments: FELIX-4501.patch, FELIX-4501.patch
>
>
> I'm seeing a deadlock where on first start the fileinstall bundle is gett=
ing stuck with itself
> as per the following two stack traces:
> {code}
> "Refresh Packages" daemon prio=3D10 tid=3D0x00007fc29c0f6800 nid=3D0x94c =
waiting on condition [0x00007fc2b9c15000]
>    java.lang.Thread.State: WAITING (parking)
> =09at sun.misc.Unsafe.park(Native Method)
> =09- parking to wait for  <0x00000000c095f950> (a java.util.concurrent.lo=
cks.ReentrantReadWriteLock$NonfairSync)
> =09at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckI=
nterrupt(AbstractQueuedSynchronizer.java:834)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued=
(AbstractQueuedSynchronizer.java:867)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstr=
actQueuedSynchronizer.java:1197)
> =09at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Re=
entrantReadWriteLock.java:945)
> =09at org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.=
java:171)
> =09at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(Bu=
ndleContextImpl.java:771)
> =09at java.security.AccessController.doPrivileged(Native Method)
> =09at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(Bun=
dleContextImpl.java:764)
> =09at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(Bund=
leHost.java:510)
> =09at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(Abs=
tractBundle.java:566)
> =09at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Fr=
amework.java:1207)
> =09at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBu=
ndle(PackageAdminImpl.java:326)
> =09at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDe=
lta(PackageAdminImpl.java:467)
> =09at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolve=
Bundles(PackageAdminImpl.java:251)
> =09- locked <0x00000000c0cbc1f8> (a org.eclipse.osgi.framework.internal.c=
ore.PackageAdminImpl)
> =09at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(Pac=
kageAdminImpl.java:174)
> =09at java.lang.Thread.run(Thread.java:744)
>    Locked ownable synchronizers:
> =09- None
> {code}
> {code}
> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=3D10 =
tid=3D0x00007fc2ac01a000 nid=3D0x920 waiting on condition [0x00007fc2ba7210=
00]
>    java.lang.Thread.State: WAITING (parking)
> =09at sun.misc.Unsafe.park(Native Method)
> =09- parking to wait for  <0x00000000c51bd048> (a java.util.concurrent.Co=
untDownLatch$Sync)
> =09at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckI=
nterrupt(AbstractQueuedSynchronizer.java:834)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShar=
edInterruptibly(AbstractQueuedSynchronizer.java:994)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared=
Interruptibly(AbstractQueuedSynchronizer.java:1303)
> =09at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> =09at org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInsta=
ll.java:319)
> =09at org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(Dire=
ctoryWatcher.java:674)
> =09at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(Di=
rectoryWatcher.java:495)
> =09at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(Dire=
ctoryWatcher.java:358)
> =09at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(Director=
yWatcher.java:310)
>    Locked ownable synchronizers:
> =09- None
> {code}
> You can see that the refresh event will never return (to tear down  the l=
atch) as long as the {{FileInstall.stop}} operation can't get the lock in t=
o directory which it's currently holding during the refresh operation!
> What seems strange is that fileinstall is adding itself to the list of bu=
ndles to refresh during the=20
> {code}
> findBundlesWithOptionalPackagesToRefresh(toRefresh);
> {code}
> call.
> It would seem that this could be solved if it were possible to pass the p=
roperty:
> {{felix.fileinstall.optionalImportRefreshScope=3Dmanaged}}
> provided that file install isn't part of the managed set.
> However this property cannot be passed (via system property, bundle conte=
xt, framework properties) except during a service update lifecycle on a man=
aged service, so you can't bootstrap the system from scratch.
> Guillaume Nodet suggested that a good work around would be to simply allo=
w all properties to be retrievable from the bundle context (framework prope=
rties).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)