[
https://issues.apache.org/jira/browse/KARAF-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned KARAF-6068:
-------------------------------------------
Assignee: (was: Jean-Baptiste Onofré)
> 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.0.7, 4.1.5
> Environment: JDK 8
> Windows, Linux
> Reporter: Andrei Shakirin
> 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
(v8.3.4#803005)
