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

WildFly 8.2.X hangs after REdeployment and gets unreponsive

我们将应用程序从 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 请求不是 concurrent/sequential,就会被处理。当两个并行 JAX-RS 请求到来时,任何 Jax-RS 请求(包括前两个并行请求)都将简单地超时。无论将 HTTP 请求分派到哪个 REST 资源。

我调试了一下 RestEasy 3.0.10 library and detected that the code simply waits for the dispatched REST method to return。另一方面,一旦挂起,它就永远不会进入我的 REST 方法(我的 Rest 资源)。

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

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>