subject:"Re\: \[pax\-cdi\] Thread dead lock with osgi refresh"

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-10 Thread Guillaume Nodet

I pushed a fix anyway.

2017-05-10 13:50 GMT+02:00 Pavel :

> Simon said which configuration must be used. Weld developers said this
> configuration
> can be set via system settings -Dorg.jboss.weld.bootstrap.
> concurrentDeployment=false
> so there is no need to modify PAX-CDI code.
>
> If someone has the same problem he can find more information here:
> https://issues.jboss.org/browse/WELD-2383
>
> вторник, 9 мая 2017 г., 23:58:57 UTC+3 пользователь Pavel написал:
>
>> Hi Simon
>>
>> Thank you very much! This is really helped. But what are the consequences
>> of such workaround?
>>
>> Best regards, Pavel
>>
>> вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>>>
>>> This is probably suboptimal, but it may be good enough:
>>>
>>> When configuring the weld bootstrap at
>>>
>>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-c
>>> di-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiCon
>>> tainer.java#L120
>>>
>>> it is possible to disable concurrent deployment by  chaining
>>> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>>>
>>> That should either solve the deadlock, or move it :)
>>>
>>> Simon
>>>
>>> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Guillaume Nodet

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-10 Thread Pavel

Simon said which configuration must be used. Weld developers said this 
configuration 
can be set via system settings 
-Dorg.jboss.weld.bootstrap.concurrentDeployment=false
so there is no need to modify PAX-CDI code.

If someone has the same problem he can find more information here:
https://issues.jboss.org/browse/WELD-2383 

вторник, 9 мая 2017 г., 23:58:57 UTC+3 пользователь Pavel написал:
>
> Hi Simon
>
> Thank you very much! This is really helped. But what are the consequences 
> of such workaround?
>
> Best regards, Pavel
>
> вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>>
>> This is probably suboptimal, but it may be good enough:
>>
>> When configuring the weld bootstrap at 
>>
>>
>> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120
>>
>> it is possible to disable concurrent deployment by  chaining
>> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>>
>> That should either solve the deadlock, or move it :) 
>>
>> Simon
>>
>>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Pavel

Hi Simon

Thank you very much! This is really helped. But what are the consequences 
of such workaround?

Best regards, Pavel

вторник, 9 мая 2017 г., 18:43:43 UTC+3 пользователь Simon Spero написал:
>
> This is probably suboptimal, but it may be good enough:
>
> When configuring the weld bootstrap at 
>
>
> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120
>
> it is possible to disable concurrent deployment by  chaining
> .add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")
>
> That should either solve the deadlock, or move it :) 
>
> Simon
>
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Simon Spero

This is probably suboptimal, but it may be good enough:

When configuring the weld bootstrap at 

https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L120

it is possible to disable concurrent deployment by  chaining
.add(ConfigurationKey.CONCURRENT_DEPLOYMENT,"false")

That should either solve the deadlock, or move it :) 

Simon

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Pavel

Guillaume, thank you for your suggestions, but it didn't help.

I've checked all bundles manifest and only in two I found dynamic import in 
felix.scr and org.osgi.enterprise.
I removed those dynamic imports but it didn't help. Result is the same.

вторник, 9 мая 2017 г., 16:20:49 UTC+3 пользователь Guillaume Nodet написал:
>
> Or could you put a breakpoint where I told you, that would give you the 
> name of the package and the bundle by looking at the variables on the stack.
>
> 2017-05-08 12:02 GMT+02:00 Pavel :
>
>> Hi all
>>
>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>> bundles: bundleA and bundleB. 
>>
>> BundleB has CDI beans and CDI container is created for bundleB. Besides 
>> bundleB depends on bundleA.
>>
>> Now I update bundleA and do osgi refresh using this code
>>
>> Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
>> - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>>
>> Please,note that bundleB didn't change state to STARTED. When I don't use in 
>> bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok - 
>> after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug or maybe I do something wrong or something else? This is some 
>> thread dump:
>>
>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>java.lang.Thread.State: BLOCKED (on object monitor)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>  - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>  at 
>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>  at java.lang.Thread.run(Thread.java:745)
>>
>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
>> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>>java.lang.Thread.State: WAITING (on object monitor)
>>  at java.lang.Object.wait(Native Method)
>>  at java.lang.Object.wait(Object.java:502)
>>  at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>>  - locked <0xed6de970> (a [Ljava.lang.Object;)
>>  at 
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>>  at 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>>  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>  at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>>  at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>>  at 
>>

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Guillaume Nodet

Or could you put a breakpoint where I told you, that would give you the
name of the package and the bundle by looking at the variables on the stack.

2017-05-08 12:02 GMT+02:00 Pavel :

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>   at 
> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xfb14e428> (a 
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
>   at 
>

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Pavel

As I understand you DynamicImport-Package must be defined in bundle 
MANIFEST. 

So do I need to check MANIFESTs of all bundles for containing 
DynamicImport-Package
property?

вторник, 9 мая 2017 г., 16:04:53 UTC+3 пользователь Guillaume Nodet написал:
>
> Well, according to the stack trace, someone does.  I've checked weld and 
> pax-cdi bundles and they don't have any dynamic import.  Can you double 
> check all the deployed bundles ?  Maybe it's not one of you bundles, but 
> there's definitely at least one bundle which uses dynamic import.
> One way to avoid the dynamic import resolution is to back all dynamically 
> imported packages by statically imported optional packages, so that they 
> are rather statically bound than dynamically bound.
> Also, if you can easily reproduce the issue, one good way would be to put 
> a breakpoint in 
>   org.apache.felix.framework.StatefulResolver.resolve(
> StatefulResolver.java:481)
> and check which package cause the resolution.
>
>
> 2017-05-09 14:54 GMT+02:00 Pavel :
>
>> Hi Guillaume
>>
>> Thank you for your answer. But I don't use any dynamic-imports.
>>
>> вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet 
>> написал:
>>>
>>> Yeah, and I'm telling you that you should remove the DynamicImport from 
>>> your bundles in order maybe to get around those issues.
>>>
>>> 2017-05-09 14:40 GMT+02:00 Pavel :
>>>
 I wrote to Weld developers and this is the answer I got from them

 I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
 The only argument is what I wrote earlier:
 "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and 
 also 
 waiting in another thread to release this lock. But the weld-worker-1 
 thread (which holds the lock) is in state WAITING (on object monitor) 
 due to 
 org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
 which calls m_bundleLock.wait()."

 So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
 update
 operation is not supported in many cases which require osgi refresh.

 The question to community - should I create pax-cdi issue as pax-cdi is 
 the responsible
 for creating weld containers for osgi bundles or this is the end of 
 story?

 вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman 
 написал:
>
> I see two locks in JBoss Weld. 
>
> - locked <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>
>
> and I doubt that it is anything we can do about it in OPS4J to avoid 
> this.
>
>
>
> On Mon, May 8, 2017 at 6:02 PM, Pavel  wrote:
>
>> Hi all
>>
>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>> bundles: bundleA and bundleB. 
>>
>> BundleB has CDI beans and CDI container is created for bundleB. 
>> Besides bundleB depends on bundleA.
>>
>> Now I update bundleA and do osgi refresh using this code
>>
>> Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring = 
>> systemBundle.adapt(FrameworkWiring.class); 
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPED - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>>
>> Please,note that bundleB didn't change state to STARTED. When I don't 
>> use in bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok 
>> - after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug or maybe I do something wrong or something else? This is 
>> some thread dump:
>>
>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>java.lang.Thread.State: BLOCKED (on object monitor)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>  - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>>

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Guillaume Nodet

Well, according to the stack trace, someone does.  I've checked weld and
pax-cdi bundles and they don't have any dynamic import.  Can you double
check all the deployed bundles ?  Maybe it's not one of you bundles, but
there's definitely at least one bundle which uses dynamic import.
One way to avoid the dynamic import resolution is to back all dynamically
imported packages by statically imported optional packages, so that they
are rather statically bound than dynamically bound.
Also, if you can easily reproduce the issue, one good way would be to put a
breakpoint in
  org.apache.felix.framework.StatefulResolver.resolve(
StatefulResolver.java:481)
and check which package cause the resolution.


2017-05-09 14:54 GMT+02:00 Pavel :

> Hi Guillaume
>
> Thank you for your answer. But I don't use any dynamic-imports.
>
> вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet
> написал:
>>
>> Yeah, and I'm telling you that you should remove the DynamicImport from
>> your bundles in order maybe to get around those issues.
>>
>> 2017-05-09 14:40 GMT+02:00 Pavel :
>>
>>> I wrote to Weld developers and this is the answer I got from them
>>>
>>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
>>> The only argument is what I wrote earlier:
>>> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also
>>> waiting in another thread to release this lock. But the weld-worker-1
>>> thread (which holds the lock) is in state WAITING (on object monitor)
>>> due to
>>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>>> which calls m_bundleLock.wait()."
>>>
>>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle
>>> update
>>> operation is not supported in many cases which require osgi refresh.
>>>
>>> The question to community - should I create pax-cdi issue as pax-cdi is
>>> the responsible
>>> for creating weld containers for osgi bundles or this is the end of
>>> story?
>>>
>>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman
>>> написал:

 I see two locks in JBoss Weld.

 - locked <0xfd03aa50> (a java.lang.Class for 
 org.jboss.weld.util.bytecode.ClassFileUtils)


 and I doubt that it is anything we can do about it in OPS4J to avoid
 this.



 On Mon, May 8, 2017 at 6:02 PM, Pavel  wrote:

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB.
> Besides bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = 
> systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> STOPPING - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> STOPPED - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> RESOLVED - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> STARTING - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use 
> in bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok 
> - after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is 
> some thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
>

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Pavel

Hi Guillaume

Thank you for your answer. But I don't use any dynamic-imports.

вторник, 9 мая 2017 г., 15:52:03 UTC+3 пользователь Guillaume Nodet написал:
>
> Yeah, and I'm telling you that you should remove the DynamicImport from 
> your bundles in order maybe to get around those issues.
>
> 2017-05-09 14:40 GMT+02:00 Pavel :
>
>> I wrote to Weld developers and this is the answer I got from them
>>
>> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
>> The only argument is what I wrote earlier:
>> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also 
>> waiting in another thread to release this lock. But the weld-worker-1 
>> thread (which holds the lock) is in state WAITING (on object monitor) 
>> due to 
>> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
>> which calls m_bundleLock.wait()."
>>
>> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
>> update
>> operation is not supported in many cases which require osgi refresh.
>>
>> The question to community - should I create pax-cdi issue as pax-cdi is 
>> the responsible
>> for creating weld containers for osgi bundles or this is the end of story?
>>
>> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>>>
>>> I see two locks in JBoss Weld. 
>>>
>>> - locked <0xfd03aa50> (a java.lang.Class for 
>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>>
>>>
>>> and I doubt that it is anything we can do about it in OPS4J to avoid 
>>> this.
>>>
>>>
>>>
>>> On Mon, May 8, 2017 at 6:02 PM, Pavel  wrote:
>>>
 Hi all

 I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
 bundles: bundleA and bundleB. 

 BundleB has CDI beans and CDI container is created for bundleB. Besides 
 bundleB depends on bundleA.

 Now I update bundleA and do osgi refresh using this code

 Bundle systemBundle = bundleContext.getBundle(0);
 FrameworkWiring frameworkWiring = 
 systemBundle.adapt(FrameworkWiring.class); 
 frameworkWiring.refreshBundles(null);

 What I see in log of bundle B.

 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
 STOPPING - com.bundleB
 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
 UNREGISTERING - [java.lang.Object] - com.bundleB
 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
 STOPPED - com.bundleB
 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
 UNRESOLVED - com.bundleB
 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
 RESOLVED - com.bundleB
 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
 STARTING - com.bundleB
 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
 REGISTERED - [java.lang.Object] - com.bundleB

 Please,note that bundleB didn't change state to STARTED. When I don't use 
 in bundleB CDI
 beans and CDI container is not created for bundleB then everything is ok - 
 after bundleA
 update and osgi refresh bundleB reaches STARTED state.

 Is this a bug or maybe I do something wrong or something else? This is 
 some thread dump:

 "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
 nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
java.lang.Thread.State: BLOCKED (on object monitor)
at 
 org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
- waiting to lock <0xfd03aa50> (a java.lang.Class for 
 org.jboss.weld.util.bytecode.ClassFileUtils)
at 
 org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
at 
 org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
at 
 org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
at 
 org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
at 
 org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
at 
 org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

 "weld-worker-1" #144 daemon

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Guillaume Nodet

Yeah, and I'm telling you that you should remove the DynamicImport from
your bundles in order maybe to get around those issues.

2017-05-09 14:40 GMT+02:00 Pavel :

> I wrote to Weld developers and this is the answer I got from them
>
> I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
> The only argument is what I wrote earlier:
> "it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also
> waiting in another thread to release this lock. But the weld-worker-1
> thread (which holds the lock) is in state WAITING (on object monitor)
> due to
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
> which calls m_bundleLock.wait()."
>
> So there is a problem - if PAX-CDI + Weld + Felix are used then bundle
> update
> operation is not supported in many cases which require osgi refresh.
>
> The question to community - should I create pax-cdi issue as pax-cdi is
> the responsible
> for creating weld containers for osgi bundles or this is the end of story?
>
> вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>>
>> I see two locks in JBoss Weld.
>>
>> - locked <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>
>>
>> and I doubt that it is anything we can do about it in OPS4J to avoid this.
>>
>>
>>
>> On Mon, May 8, 2017 at 6:02 PM, Pavel  wrote:
>>
>>> Hi all
>>>
>>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
>>> bundles: bundleA and bundleB.
>>>
>>> BundleB has CDI beans and CDI container is created for bundleB. Besides
>>> bundleB depends on bundleA.
>>>
>>> Now I update bundleA and do osgi refresh using this code
>>>
>>> Bundle systemBundle = bundleContext.getBundle(0);
>>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
>>> frameworkWiring.refreshBundles(null);
>>>
>>> What I see in log of bundle B.
>>>
>>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STOPPING - com.bundleB
>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>> UNREGISTERING - [java.lang.Object] - com.bundleB
>>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STOPPED - com.bundleB
>>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> UNRESOLVED - com.bundleB
>>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> RESOLVED - com.bundleB
>>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>>> STARTING - com.bundleB
>>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>>> REGISTERED - [java.lang.Object] - com.bundleB
>>>
>>> Please,note that bundleB didn't change state to STARTED. When I don't use 
>>> in bundleB CDI
>>> beans and CDI container is not created for bundleB then everything is ok - 
>>> after bundleA
>>> update and osgi refresh bundleB reaches STARTED state.
>>>
>>> Is this a bug or maybe I do something wrong or something else? This is some 
>>> thread dump:
>>>
>>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>>java.lang.Thread.State: BLOCKED (on object monitor)
>>> at 
>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>> - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>> at 
>>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>> at 
>>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>> at 
>>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>> at 
>>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>> at 
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>> at 
>>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>> at 
>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>>> at 
>>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
>>> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>>>java.lang.Thread.State: WAITING (on object monitor)
>>> at java.lang.Object.wait(Native Method)
>>> at java.lang.Object.wait(Object.java:502)
>>> at

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Pavel

I wrote to Weld developers and this is the answer I got from them

I'm not sure whether this is a PAX-CDI, Felix or Weld problem.
The only argument is what I wrote earlier:
"it is true that Weld's ClassFileUtils holds 0xfd03aa50 and also 
waiting in another thread to release this lock. But the weld-worker-1 
thread (which holds the lock) is in state WAITING (on object monitor) 
due to 
org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
which calls m_bundleLock.wait()."

So there is a problem - if PAX-CDI + Weld + Felix are used then bundle 
update
operation is not supported in many cases which require osgi refresh.

The question to community - should I create pax-cdi issue as pax-cdi is the 
responsible
for creating weld containers for osgi bundles or this is the end of story?

вторник, 9 мая 2017 г., 2:14:31 UTC+3 пользователь Niclas Hedhman написал:
>
> I see two locks in JBoss Weld. 
>
> - locked <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>
>
> and I doubt that it is anything we can do about it in OPS4J to avoid this.
>
>
>
> On Mon, May 8, 2017 at 6:02 PM, Pavel  
> wrote:
>
>> Hi all
>>
>> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two 
>> bundles: bundleA and bundleB. 
>>
>> BundleB has CDI beans and CDI container is created for bundleB. Besides 
>> bundleB depends on bundleA.
>>
>> Now I update bundleA and do osgi refresh using this code
>>
>> Bundle systemBundle = bundleContext.getBundle(0);
>> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class); 
>> frameworkWiring.refreshBundles(null);
>>
>> What I see in log of bundle B.
>>
>> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STOPPING - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> UNREGISTERING - [java.lang.Object] - com.bundleB
>> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
>> - com.bundleB
>> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> UNRESOLVED - com.bundleB
>> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> RESOLVED - com.bundleB
>> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent 
>> STARTING - com.bundleB
>> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
>> REGISTERED - [java.lang.Object] - com.bundleB
>>
>> Please,note that bundleB didn't change state to STARTED. When I don't use in 
>> bundleB CDI
>> beans and CDI container is not created for bundleB then everything is ok - 
>> after bundleA
>> update and osgi refresh bundleB reaches STARTED state.
>>
>> Is this a bug or maybe I do something wrong or something else? This is some 
>> thread dump:
>>
>> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
>> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>>java.lang.Thread.State: BLOCKED (on object monitor)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>>  - waiting to lock <0xfd03aa50> (a java.lang.Class for 
>> org.jboss.weld.util.bytecode.ClassFileUtils)
>>  at 
>> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>>  at 
>> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>>  at 
>> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>>  at 
>> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>>  at 
>> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>  at java.lang.Thread.run(Thread.java:745)
>>
>> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
>> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>>java.lang.Thread.State: WAITING (on object monitor)
>>  at java.lang.Object.wait(Native Method)
>>  at java.lang.Object.wait(Object.java:502)
>>  at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>>  - locked <0xed6de970> (a [Ljava.lang.Object;)
>>  at 
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>>  at 
>>

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-09 Thread Guillaume Nodet

You should avoid the use of dynamic imports whenever possible.  Try
removing those from your bundles.


2017-05-08 12:02 GMT+02:00 Pavel :

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>   at 
> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xfb14e428> (a 
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
>   at 
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader.loadClass(BundleClassLoader.java:193)
>   at

Re: [pax-cdi] Thread dead lock with osgi refresh

2017-05-08 Thread Niclas Hedhman

I see two locks in JBoss Weld.

- locked <0xfd03aa50> (a java.lang.Class for
org.jboss.weld.util.bytecode.ClassFileUtils)


and I doubt that it is anything we can do about it in OPS4J to avoid this.



On Mon, May 8, 2017 at 6:02 PM, Pavel  wrote:

> Hi all
>
> I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> bundles: bundleA and bundleB.
>
> BundleB has CDI beans and CDI container is created for bundleB. Besides
> bundleB depends on bundleA.
>
> Now I update bundleA and do osgi refresh using this code
>
> Bundle systemBundle = bundleContext.getBundle(0);
> FrameworkWiring frameworkWiring = systemBundle.adapt(FrameworkWiring.class);
> frameworkWiring.refreshBundles(null);
>
> What I see in log of bundle B.
>
> 2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPING 
> - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> UNREGISTERING - [java.lang.Object] - com.bundleB
> 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? | BundleEvent STOPPED 
> - com.bundleB
> 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? | BundleEvent 
> UNRESOLVED - com.bundleB
> 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? | BundleEvent RESOLVED 
> - com.bundleB
> 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? | BundleEvent STARTING 
> - com.bundleB
> 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? | ServiceEvent 
> REGISTERED - [java.lang.Object] - com.bundleB
>
> Please,note that bundleB didn't change state to STARTED. When I don't use in 
> bundleB CDI
> beans and CDI container is not created for bundleB then everything is ok - 
> after bundleA
> update and osgi refresh bundleB reaches STARTED state.
>
> Is this a bug or maybe I do something wrong or something else? This is some 
> thread dump:
>
> "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000 
> nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
>   - waiting to lock <0xfd03aa50> (a java.lang.Class for 
> org.jboss.weld.util.bytecode.ClassFileUtils)
>   at 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
>   at 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
>   at 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
>   at 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
>
> "weld-worker-1" #144 daemon prio=5 os_prio=0 tid=0x7f3e08042800 
> nid=0x1dc6 in Object.wait() [0x7f3dd967e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   at java.lang.Object.wait(Object.java:502)
>   at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332)
>   - locked <0xed6de970> (a [Ljava.lang.Object;)
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:481)
>   at 
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1652)
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1552)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
>   at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
>   at 
> org.apache.xbean.osgi.bundle.util.DelegatingBundle.loadClass(DelegatingBundle.java:170)
>   at 
> org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>   - locked <0xfb14e428> (a 
> org.ops4j.pax.cdi.weld.impl.util.BundleClassLoader)
>   at 
>

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

Re: [pax-cdi] Thread dead lock with osgi refresh

13 matches

Site Navigation

Mail list logo

Footer information