Karaf重启后Blueprint Bundle容器启动失败异常求助

使用Karaf 4.2.16版本，首次启动时一切正常，但重启后10分钟宽限期结束后出现如下Blueprint容器启动异常：

2023-08-10T05:38:55,140 | ERROR | Blueprint Extender: 3 | BlueprintContainerImpl           | 212 - org.apache.aries.blueprint.core - 1.10.3 | Unable to start container for blueprint bundle com.my_app.access.auth.cdo/4.0.0.SNAPSHOT due to unresolved dependencies [(objectClass=com.my_app.common.util.ICdoSessionFactory)]
java.util.concurrent.TimeoutException: null
        at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:393) [bundleFile:1.10.3]
        at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45) [bundleFile:1.10.3]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_382]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_382]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_382]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_382]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_382]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_382]
        at java.lang.Thread.run(Thread.java:750) [?:1.8.0_382]

删除data目录可临时解决，但并非合理方案。异常的bundle与提供依赖的bundle均处于Active状态，应用也能正常运行：

karaf@root()> list -l | grep access.auth.cdo
45 │ Active   │ 100 │ 4.0.0.SNAPSHOT            │ mvn:com.my_app.access/com.my_app.access.auth.cdo/4.0.0-SNAPSHOT
karaf@root()> list -l | grep common.util
61 │ Active   │  60 │ 4.0.0.SNAPSHOT            │ mvn:com.my_app.common/com.my_app.common.util/4.0.0-SNAPSHOT

1. 检查Blueprint服务注册与依赖配置 #

• 确认com.my_app.common.util的Blueprint XML中，ICdoSessionFactory服务是否在容器启动时及时注册，避免异步延迟初始化。检查<service>标签的配置，确保没有设置延迟加载逻辑。
• 若业务允许，可将com.my_app.access.auth.cdo中对ICdoSessionFactory的引用改为可选依赖，在Blueprint XML中设置availability="optional"，避免因服务注册延迟触发超时。

2. 调整Blueprint超时与线程配置 #

编辑Karaf配置文件etc/org.apache.aries.blueprint.core.cfg：

• 修改blueprint.container.timeout参数，延长超时时间（默认600000毫秒=10分钟），例如设置为1200000（20分钟）；生产环境不建议设为0（无限等待）。
• 增加blueprint.extender.threads参数的值，提升Blueprint扩展器的线程处理能力，避免线程池阻塞导致服务注册延迟。

3. 精准清理缓存而非整个data目录 #

无需删除整个data目录，仅清理缓存目录data/cache即可，这样能保留自定义配置，清除bundle的缓存状态，重启后Karaf会重新生成缓存，避免首次启动的状态残留问题。

4. 优化bundle启动级别与依赖顺序 #

• 调整com.my_app.common.util的启动级别，确保其在依赖它的bundle之前完成服务注册。例如通过Karaf命令调整启动级别：

  start-level -s 61 70
  

• 在com.my_app.access.auth.cdo的MANIFEST.MF中添加Require-Bundle: com.my_app.common.util，明确声明依赖关系，强制启动顺序。

5. 排查服务注册细节日志 #

开启Blueprint调试日志，编辑etc/org.ops4j.pax.logging.cfg添加：

log4j2.logger.blueprint.name = org.apache.aries.blueprint
log4j2.logger.blueprint.level = DEBUG

重启Karaf后，查看日志确认ICdoSessionFactory服务的注册时机，是否在access.auth.cdo的Blueprint容器启动前完成注册，排查是否存在注册失败的隐性异常。

内容的提问来源于stack exchange，提问作者Ubuntu Learner