Re: [equinox-dev] deadlock in fileinstall on equinox

[Daniel Rolka <Daniel.Rolka@xxxxxxxxxx>]

daniel.rolka@gmail.comDaniel Rolka
IBM SWG Lab, Cracow, Poland

IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18
30 -150 Kraków
tel. +48 12 628 9993

NIP: 526-030-07-24
Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS
KRS 0000012941, Kapitał zakładowy: 42.153.600 PLN

From:	Thomas Watson <tjwatson@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date:	04/29/2014 09:10 PM
Subject:	Re: [equinox-dev] deadlock in fileinstall on equinox
Sent by:	equinox-dev-bounces@xxxxxxxxxxx

---

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

Raymond
Auge ---04/29/2014 01:14:44 PM---It would seem that this could be solved
it it were possible to pass the property:

From: Raymond Auge <raymond.auge@xxxxxxxxxxx>
To: Apache Felix Developers <dev@xxxxxxxxxxxxxxxx>,
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 04/29/2014 01:14 PM
Subject: Re: [equinox-dev] deadlock
in fileinstall on equinox
Sent by: equinox-dev-bounces@xxxxxxxxxxx

---

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@xxxxxxxxxxx>
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev