[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] fileinstall & equinox solution

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
hargrave@xxxxxxxxxx

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





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





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
hargrave@xxxxxxxxxx

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





From:        
Raymond Auge <raymond.auge@xxxxxxxxxxx>
To:        
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:        
2014/09/29 13:47
Subject:        
Re: [equinox-dev] fileinstall & equinox solution
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx





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 <
hargrave@xxxxxxxxxx> wrote:
Stacktrace?

--

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance
hargrave@xxxxxxxxxx

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





From:        
Raymond Auge <raymond.auge@xxxxxxxxxxx>
To:        
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, Apache Felix Developers <dev@xxxxxxxxxxxxxxxx>
Date:        
2014/09/29 13:07
Subject:        
Re: [equinox-dev] fileinstall & equinox solution
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx





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 <
hargrave@xxxxxxxxxx> 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
hargrave@xxxxxxxxxx

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





From:        
Raymond Auge <raymond.auge@xxxxxxxxxxx>
To:        
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, Apache Felix Developers <dev@xxxxxxxxxxxxxxxx>
Date:        
2014/09/29 12:52
Subject:        
[equinox-dev] fileinstall & equinox solution
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx






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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev