This thread owns that lock:

"fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10 
tid=0x00007f7324017000 nid=0x2b89 waiting on condition 
[0x00007f738bdfc000]
   java.lang.Thread.State: WAITING (parking)
                 at sun.misc.Unsafe.park(Native Method)
                 - parking to wait for  <0x0000000787811a98> (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)

And then while holding that lock, calls refresh on the framework which is 
an asynchronous operation.

This seems like a bad design for file installer. You generally should not 
hold lock while triggering an async operation that can call back into you 
on another thread.

File installer is borked. If you can figure out how to not get fail 
installer swept up on the refresh you can avoid the design flaw in file 
installer but file installer needs a better locking design. I do not see 
any issue with Equinox here.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   BJ Hargrave/Austin/IBM@IBMUS
To:     Equinox development mailing list <equinox-dev@eclipse.org>
Date:   2014/09/29 14:13
Subject:        Re: [equinox-dev] fileinstall & equinox solution
Sent by:        equinox-dev-boun...@eclipse.org



The second thread dump shows that the fileinstaller BundleActivator.stop 
method is blocked 

"Refresh Thread: Equinox Container: b0d7b641-fc47-0014-11e3-e5afcb018d39" 
daemon prio=10 tid=0x00007f732a74e800 nid=0x2b87 waiting on condition 
[0x00007f738bffd000] 
   java.lang.Thread.State: WAITING (parking) 
                 at sun.misc.Unsafe.park(Native Method) 
                 - parking to wait for  <0x0000000783a3fa20> (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.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827)
 

                 at 
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
 

                 at java.security.AccessController.doPrivileged(Native 
Method) 
                 at 
org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820)
 


on the same lock as the file installer's directory watcher. 

"fileinstall-/home/rotty/AS/liferay-portal/osgi/modules" daemon prio=10 
tid=0x00007f732401f800 nid=0x2b8b waiting on condition 
[0x00007f738bbfa000] 
   java.lang.Thread.State: WAITING (parking) 
                 at sun.misc.Unsafe.park(Native Method) 
                 - parking to wait for  <0x0000000783a3fa20> (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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
 

                 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
 

                 at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:776)
 

                 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:355)
 

                 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
 

  
This seems like the file installer is blocking Bundle.stop. It would seem 
that BundleActivator.stop should interrupt those watcher threads to allow 
an orderly shutdown. 

There may be a second order issue of why file installer is getting swept 
up on the refresh. But the first order problem is why wont file installer 
stop when requested. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:        Raymond Auge <raymond.a...@liferay.com> 
To:        Equinox development mailing list <equinox-dev@eclipse.org> 
Date:        2014/09/29 13:47 
Subject:        Re: [equinox-dev] fileinstall & equinox solution 
Sent by:        equinox-dev-boun...@eclipse.org 



Sorry, I thought I linked one, but apparently missed the link. 

when I did have pieces which may have pulled in FI 
https://gist.github.com/rotty3000/33a5f1fb0b1c3627a20a 

after removing those pieces 
https://gist.github.com/rotty3000/8c0a41b6aa633c1aebd7 



On Mon, Sep 29, 2014 at 1:40 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: 
Stacktrace? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:        Raymond Auge <raymond.a...@liferay.com> 
To:        Equinox development mailing list <equinox-dev@eclipse.org>, 
Apache Felix Developers <d...@felix.apache.org> 
Date:        2014/09/29 13:07 
Subject:        Re: [equinox-dev] fileinstall & equinox solution 
Sent by:        equinox-dev-boun...@eclipse.org 



Sorry I forgot to mention I'm cross posting to felix list also. 

Anyhow, here is a stacktrace which shows the locking (search for 
fileinstall). 

- Ray 

On Mon, Sep 29, 2014 at 12:57 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: 

Is there a bug/issue with the details? I don't know any details here. What 
is the "concurrency issue with package refresh"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:        Raymond Auge <raymond.a...@liferay.com> 
To:        Equinox development mailing list <equinox-dev@eclipse.org>, 
Apache Felix Developers <d...@felix.apache.org> 
Date:        2014/09/29 12:52 
Subject:        [equinox-dev] fileinstall & equinox solution 
Sent by:        equinox-dev-boun...@eclipse.org 




Will there ever be a solution to the fileinstall on equinox issue? 

It seems that fileinstall has not worked on equinox for some time due to 
the concurrency issue with package refresh. 

I believe 3.1.10 is the last version that works on equinox. 

-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to