felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Augé (JIRA) <j...@apache.org>
Subject [jira] [Commented] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
Date Thu, 26 Mar 2015 17:16:54 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382259#comment-14382259
] 

Raymond Augé commented on FELIX-4501:
-------------------------------------

{code}
[rotty@rotty-XPS-15-9530 (trunk $>) fileinstall]$ mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; 2015-03-13T16:10:27-04:00)
Maven home: /home/rotty/MY-SHARE/LOBS/TAR-BIN/apache-maven-3.3.1
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-31-generic", arch: "amd64", family: "unix"
{code}

> Impossible to set the felix.fileinstall.optionalImportRefreshScope property 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é
>            Priority: Minor
>
> I'm seeing a deadlock where on first start the fileinstall bundle is getting stuck with
itself
> as per the following two stack traces:
> {code}
> "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
> {code}
> {code}
> "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
> {code}
> 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 
> {code}
> findBundlesWithOptionalPackagesToRefresh(toRefresh);
> {code}
> call.
> It would seem that this could be solved if it were possible to pass the property:
> {{felix.fileinstall.optionalImportRefreshScope=managed}}
> provided that file install isn't part of the managed set.
> However this property cannot be passed (via system property, bundle context, framework
properties) except during a service update lifecycle on a managed service, so you can't bootstrap
the system from scratch.
> Guillaume Nodet suggested that a good work around would be to simply allow all properties
to be retrievable from the bundle context (framework properties).



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

Mime
View raw message