WildFly 8.2.X 在部署后挂起并且没有响应

Question

我们将应用程序从 JBoss AS 7.1.1 迁移到 WildFly 8.2.X（8.2.0-Final 和 8.2.1-Final）并发现以下问题：

1. 第一次部署工作正常（比 JBoss AS 7.1.1 慢，但在我看来这是另一个问题）。
2. 在我们重新部署相同的 EAR 文件（从 Eclipse 或从 Web 界面）之后，只要 JAX-RS 请求不是并发/顺序的，它们就会被处理。当两个并行 JAX-RS 请求到来时，任何 Jax-RS 请求（包括前两个并行）都将简单地超时。无论 HTTP 请求将被分派到哪个 REST 资源。

我对@9​​87654321@ 库进行了一些调试，发现代码只是在等待the dispatched REST method to return。另一方面，一旦挂起，它就永远不会进入我的 REST 方法（我的 Rest 资源）。

关于如何进一步调试的任何想法？我无法在完全相同的服务器上使用其他 EAR 应用程序重现此行为。

Answer 1

在与jconsole 进一步检查后，我看到一个死锁被创建：一个线程在等待

org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:231) org.apache.log4j.JBossAppenderHandler.doPublish(JBossAppenderHandler.java:42) org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79) org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296) org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304) org.jboss.logmanager.Logger.logRaw(Logger.java:721) org.jboss.logmanager.Logger.log(Logger.java:506) org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71) - locked java.lang.StringBuilder@497a942 org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143) org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164) - locked sun.nio.cs.UTF_8$Decoder@e92e69 java.io.PrintStream.write(PrintStream.java:482) - locked java.io.PrintStream@d4482dd

另一个在等待

java.io.PrintStream.flush(PrintStream.java:335) org.jboss.stdio.StdioContext$DelegatingPrintStream.flush(StdioContext.java:216) sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) - locked java.io.OutputStreamWriter@7797a41d java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:59) org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:324) org.apache.log4j.WriterAppender.append(WriterAppender.java:162)

问题似乎在于 EAR 应用程序带有它自己的 log4j 库，但不排除 WildFly 中的那个。 jboss-deployment-structure.xml 文件中的以下部分似乎解决了问题，disabling the loading of the logging subsystem：

<jboss-deployment-structure>
  <deployment>
     <!-- exclude-subsystem prevents a subsystems deployment unit processors running on a deployment -->
     <!-- which gives basically the same effect as removing the subsystem, but it only affects single deployment -->
     <exclude-subsystems>
        <subsystem name="logging" />
    </exclude-subsystems>
  </deployment>
</jboss-deployment-structure>