3

当 aBundleActivator运行一个后台线程，并且该后台线程出现不可恢复的错误时，应该怎么办？

public class Activator implements BundleActivator
{
   private Thread t;
   @Override
   public void start(BundleContext context) throws Exception
   {
      t = new Thread(new Runnable(){
            @Override
             public void run(){
                while (!Thread.interrupted()){
                  // do something which may throw a runtime exception
               }
            }
         });
      t.start();
   }
   @Override void stop(BundleContext context) throws Exception
   {
      t.interrupt();
      t.join();
   }
}

通过这个示例，我如何通知 OSGi 框架线程已死并且捆绑包已有效停止且未运行？

4

4 回答 4

2

看看 Peter Kriens 如何在本文中执行类似的操作。对于他的示例，您需要做的就是在他的 catch 块中调用激活器上的停止，而不是执行 printStackTrace。

于 2013-01-09T22:23:53.183 回答
2

可能最好的办法就是记录错误，最好是记录到 OSGi 日志服务。然后管理员可以检测捆绑包的问题并决定要做什么。您应该将其作为声明式服务组件而不是作为BundleActivator.

我不认为捆绑包应该尝试自行停止。这使捆绑包处于一种奇怪的状态......它已停止但仍有代码运行......即调用stop(). 这可能只是短暂的一段时间，但感觉不对。

处于 ACTIVE 状态的包不一定必须一直“做某事”，它只是有可能“做某事”。失败的事实不应该真正影响包的外部状态。

于 2013-01-10T17:27:16.160 回答
1

据我所知，OSGi 在这种特殊情况下无法直接帮助您。我通常依靠未捕获的异常处理程序来获得线程崩溃的通知，或者我实现某种形式的 SW 看门狗。

关键是产生多个线程并成功完成其启动方法的包仍然保持活动状态，即使其中一个线程在一段时间后崩溃。

于 2013-01-09T22:12:51.220 回答
1

尼尔（像往常一样）非常正确。捆绑包永远不应停止自身，因为这会干扰管理代理。启动/停止是从该管理代理到捆绑包的消息，表明它应该处于活动状态。如果捆绑包无法履行其职责，您应该记录该消息，稍等片刻（越来越长）并重试。

日志是通知的地方，停止捆绑会严重混合级别。

于 2013-01-11T07:20:19.863 回答