4

有时当我停止我的 Liferay 模块时（例如，当我将其 JAR 的新版本放入时deploy/），模块拒绝停止。

虽然模块应该进入“已解决”状态，但它永远处于“停止”状态：

OSGi 生命周期

通常是由于线程未在某处终止，或者网络连接未正确关闭，而且调查通常很痛苦。

我的问题：如何更有效地找出这个 Liferay 模块的问题是什么？

我尝试了什么：

  • 在 Gogo Shelldiag <module id>中似乎没有提供任何关于模块拒绝离开“停止”状态的有价值信息。
  • jstack输出数千行，其中绝大多数在所讨论的 Liferay 模块之外。如果有一种方法可以仅为我的模块显示 jstack 信息，那就太好了。
4

2 回答 2

1

首先，找到你的 webapp 服务器的 PID：

ps aux | grep tomcat

如果您正在运行除 tomcat 之外的另一台服务器，或者如果您有多个实例正在运行，请调整该命令。

然后，将该服务器的所有线程转储到一个文件中：

jstack 12345 > jstack.txt

其中 12345 是您在第一步中找到的 PID。

然后，查看你的包的源代码，找到服务激活器。它通常看起来像这样：

package fr.free.nrw;

[import section]

public class ServiceActivator implements BundleActivator {

    private ServiceRegistration registration;

    @Override
    public void start(BundleContext context) throws Exception {
        registration = context.registerService(
            MyService.class.getName(), new MyServiceImpl(), null);
    }

    @Override
    public void stop(BundleContext context) throws Exception {
        registration.unregister();
    }
}

记笔记：

  • 命名空间，
  • 班级名称，
  • 停止方法名称。

例如在上面的例子中它们是fr.free.nrw,ServiceActivator和stop, 并从这三个中得到全名fr.free.nrw.ServiceActivator.stop。

现在打开jstack.txt并搜索全名。即使文件有数千行长，也很可能只有一次命中，这就是有问题的线程：

at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222)
at fr.free.nrw.ServiceActivator.stop(ServiceActivator.java:30)
at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:830)
at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:823)

在这个文件中，直到段落的开头，这将是这样的：

"fileinstall-/home/nico/p/liferay/osgi/modules" #37 daemon prio=5 os_prio=0 tid=0x00007f39480e3000 nid=0x384f waiting on condition [0x00007f395d169000]
  java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000eb8defb8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

掌握了这些信息，您将知道发生了什么样的线程问题，并且您将能够使用通常的 Java 线程调试技术来解决它 ( 1 2 )。

于 2017-08-02T03:03:36.430 回答
0

您共享的 Activator 永远不应阻塞 stop 方法。所以我怀疑它会导致你描述的行为。

于 2017-08-01T10:50:34.860 回答