You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Raymond Auge <ra...@liferay.com> on 2014/04/29 19:28:55 UTC
deadlock in fileinstall on equinox
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é* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: deadlock in fileinstall on equinox
Posted by Marcel Offermans <ma...@luminis.eu>.
The problem here is that file install cannot dictate the framework what to refresh. The refresh method takes an initial set of bundles, but the framework calculates a "dependency closure" (see 7.6.1 of the spec for example). If that closure includes file install, then this issue occurs. The only way file install can solve this is by making sure it never gets included by not importing anything or by modifying the code so it does not deadlock. I think that modifying the code is the best option, because that ensures that this can never happen. Any other solution is probably very fragile as *any* bundle can trigger a refresh that might include file install.
Greetings, Marcel
On 29 Apr 2014, at 21:22 pm, Raymond Auge <ra...@liferay.com> wrote:
> I don't think fileinstall should ever really be able to refresh itself
> exactly for the reason that it's going to create a deadlock.
>
> It would appear to me that fileinstall should just ignore anything that it
> can't itself manage, such as itself.
>
> I'm actually wondering why
>
> felix.fileinstall.optionalImportRefreshScope=managed
>
> isn't the default
>
> The default is null which equates to all framework bundles which seems is
> leading to the problem.
>
> - Ray
>
>
> On Tue, Apr 29, 2014 at 3:14 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
>> My question was about why fileinstall refreshes itself. It must be because
>> you deploy either configadmin or a log service as those are the only two
>> optional imports on fileinstall.
>>
>>
>> 2014-04-29 20:53 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>>
>>> I'm not using config admin at all. Rather, the only path to setting the
>> bit
>>> I need is via service update lifecycle.
>>>
>>> - Ray
>>>
>>>
>>> On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>>
>>>> Are you trying to use fileinstall to deploy configadmin ?
>>>> That's not really supported, but it should not be very difficult to
>>>> support.
>>>> Please raise a JIRA.
>>>>
>>>> I think allowing all configuration bits to be available from the bundle
>>>> context would be a good work around.
>>>>
>>>>
>>>> 2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>>>>
>>>>> 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@liferay.com
>>>>>> 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é* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>> (@rotty3000)
>>>>>> Senior Software Architect
>>>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>> (@rotty3000)
>>>>> Senior Software Architect
>>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect
>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>>
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: deadlock in fileinstall on equinox
Posted by Raymond Auge <ra...@liferay.com>.
I don't think fileinstall should ever really be able to refresh itself
exactly for the reason that it's going to create a deadlock.
It would appear to me that fileinstall should just ignore anything that it
can't itself manage, such as itself.
I'm actually wondering why
felix.fileinstall.optionalImportRefreshScope=managed
isn't the default
The default is null which equates to all framework bundles which seems is
leading to the problem.
- Ray
On Tue, Apr 29, 2014 at 3:14 PM, Guillaume Nodet <gn...@apache.org> wrote:
> My question was about why fileinstall refreshes itself. It must be because
> you deploy either configadmin or a log service as those are the only two
> optional imports on fileinstall.
>
>
> 2014-04-29 20:53 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>
> > I'm not using config admin at all. Rather, the only path to setting the
> bit
> > I need is via service update lifecycle.
> >
> > - Ray
> >
> >
> > On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <gn...@apache.org>
> > wrote:
> >
> > > Are you trying to use fileinstall to deploy configadmin ?
> > > That's not really supported, but it should not be very difficult to
> > > support.
> > > Please raise a JIRA.
> > >
> > > I think allowing all configuration bits to be available from the bundle
> > > context would be a good work around.
> > >
> > >
> > > 2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> > >
> > > > 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@liferay.com
> > > > >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é* <http://www.liferay.com/web/raymond.auge/profile>
> > > > > (@rotty3000)
> > > > > Senior Software Architect
> > > > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > (@rotty3000)
> > > > Senior Software Architect
> > > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> > > >
> > >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect
> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> >
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: deadlock in fileinstall on equinox
Posted by Guillaume Nodet <gn...@apache.org>.
My question was about why fileinstall refreshes itself. It must be because
you deploy either configadmin or a log service as those are the only two
optional imports on fileinstall.
2014-04-29 20:53 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> I'm not using config admin at all. Rather, the only path to setting the bit
> I need is via service update lifecycle.
>
> - Ray
>
>
> On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <gn...@apache.org>
> wrote:
>
> > Are you trying to use fileinstall to deploy configadmin ?
> > That's not really supported, but it should not be very difficult to
> > support.
> > Please raise a JIRA.
> >
> > I think allowing all configuration bits to be available from the bundle
> > context would be a good work around.
> >
> >
> > 2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> >
> > > 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@liferay.com
> > > >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é* <http://www.liferay.com/web/raymond.auge/profile>
> > > > (@rotty3000)
> > > > Senior Software Architect
> > > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> > > >
> > > >
> > >
> > >
> > > --
> > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > (@rotty3000)
> > > Senior Software Architect
> > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> > >
> >
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
Re: deadlock in fileinstall on equinox
Posted by Raymond Auge <ra...@liferay.com>.
created https://issues.apache.org/jira/browse/FELIX-4501
On Tue, Apr 29, 2014 at 2:53 PM, Raymond Auge <ra...@liferay.com>wrote:
> I'm not using config admin at all. Rather, the only path to setting the
> bit I need is via service update lifecycle.
>
> - Ray
>
>
> On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <gn...@apache.org>wrote:
>
>> Are you trying to use fileinstall to deploy configadmin ?
>> That's not really supported, but it should not be very difficult to
>> support.
>> Please raise a JIRA.
>>
>> I think allowing all configuration bits to be available from the bundle
>> context would be a good work around.
>>
>>
>> 2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>>
>> > 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@liferay.com
>> > >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é* <http://www.liferay.com/web/raymond.auge/profile>
>> > > (@rotty3000)
>> > > Senior Software Architect
>> > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>> > >
>> > >
>> >
>> >
>> > --
>> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> > (@rotty3000)
>> > Senior Software Architect
>> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>> >
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: deadlock in fileinstall on equinox
Posted by Raymond Auge <ra...@liferay.com>.
I'm not using config admin at all. Rather, the only path to setting the bit
I need is via service update lifecycle.
- Ray
On Tue, Apr 29, 2014 at 2:47 PM, Guillaume Nodet <gn...@apache.org> wrote:
> Are you trying to use fileinstall to deploy configadmin ?
> That's not really supported, but it should not be very difficult to
> support.
> Please raise a JIRA.
>
> I think allowing all configuration bits to be available from the bundle
> context would be a good work around.
>
>
> 2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>
> > 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@liferay.com
> > >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é* <http://www.liferay.com/web/raymond.auge/profile>
> > > (@rotty3000)
> > > Senior Software Architect
> > > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> > >
> > >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect
> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> >
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: deadlock in fileinstall on equinox
Posted by Guillaume Nodet <gn...@apache.org>.
Are you trying to use fileinstall to deploy configadmin ?
That's not really supported, but it should not be very difficult to support.
Please raise a JIRA.
I think allowing all configuration bits to be available from the bundle
context would be a good work around.
2014-04-29 20:13 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> 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@liferay.com
> >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é* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect
> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> >
> >
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
Re: deadlock in fileinstall on equinox
Posted by Raymond Auge <ra...@liferay.com>.
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 <ra...@liferay.com>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é* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)