[jira] [Commented] (KARAF-6068) Karaf hangs by bundle resolving (felix resolver)

["Andrei Shakirin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733156#comment-16733156 ] 

Andrei Shakirin commented on KARAF-6068:
----------------------------------------

Yes, it happens under Linux and Windows.
I have prepared the archive illustrating the problem:
https://www.dropbox.com/s/4kpi0bkmuszg3ja/karaf-hanging.zip?dl=0

> Karaf hangs by bundle resolving (felix resolver)
> ------------------------------------------------
>
>                 Key: KARAF-6068
>                 URL: https://issues.apache.org/jira/browse/KARAF-6068
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf
>    Affects Versions: 4.1.5
>         Environment: JDK 8
> Windows, Linux
>            Reporter: Andrei Shakirin
>            Assignee: Jean-Baptiste Onofré
>            Priority: Critical
>         Attachments: karaf-hangs-stacktrace.txt, tesb.log, threads-cpu.png
>
>
> I faced following situation in project uses Karaf as deployment container for microservices:
> 1) bundle A is installed with feature A and exports java packages xxx.yyy in version 10.2.0
> 2) additionally, bundle B was created and installed with feature B. Bundle B exporting the same java packages (xxx.yyy)  as bundle A, but with another version 1.1.0
> Problem: as soon as other modules importing java packages (xxx.yyy) with version [1.1, 2.0) - Karaf completely hangs on startup. There are no logs describing the problem. The last log statement is about JMX registration.
> Karaf JVM takes about 90% CPU - looks like infinite loop.
> The thread dump shows that threads occupied CPU are the following:
> {code}
> "pool-38-thread-8" #245 prio=5 os_prio=0 tid=0x000000001cd94000 nid=0x3094 runnable [0x0000000029f0e000]
>    java.lang.Thread.State: RUNNABLE
>         at org.apache.felix.resolver.util.ArrayMap.getOrCompute(ArrayMap.java:74)
>         at org.apache.felix.resolver.ResolverImpl.addUsedBlame(ResolverImpl.java:1284)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1110)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1111)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1111)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1105)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1105)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1105)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1105)
>         at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:1105)
>         at org.apache.felix.resolver.ResolverImpl.computeUses(ResolverImpl.java:872)
>         at org.apache.felix.resolver.ResolverImpl.access$500(ResolverImpl.java:59)
>         at org.apache.felix.resolver.ResolverImpl$6.run(ResolverImpl.java:1231)
>         at org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run(ResolverImpl.java:2442)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> {code}
> Full logs and thread dumps are attached.
> The problem makes diagnostic of package exports/imports issues completely impossible. 
> I will try to reproduce it on simple example, but perhaps you can start analyse based om thread dumps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)