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] [Updated] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
Date Tue, 29 Apr 2014 19:14:16 GMT

     [ https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Raymond Augé updated FELIX-4501:
--------------------------------

    Description: 
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).

  was:
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}}

but this property cannot be passed 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).


> 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.2#6252)

Mime
View raw message