WildFly 8.2.X hangs after REdeployment and gets unreponsive

Question

We move an application from JBoss AS 7.1.1 to WildFly 8.2.X (8.2.0-Final and 8.2.1-Final) and discovered the following problem:

First deployment works OK (slower than with JBoss AS 7.1.1, but that seems to me to be another problem).
After we redeploy the same EAR file (either from Eclipse or from the Web Interface), the JAX-RS requests are processed as long as they are not concurrent/sequential. When two parallel JAX-RS requests come, any Jax-RS requests (incl. the first two parallel) will simply timeout. No matter to which REST Resource the HTTP Requests will be dispatched.

I have debugged a bit the RestEasy 3.0.10 library and detected that the code simply waits for the dispatched REST method to return. On the other side once hanged, it never enters my REST method (of my Rest Resource).

Any ideas on how to debug further? I cannot reproduce this behavior with other EAR applications on exactly the same server.

score 0 · Accepted Answer · edited May 23 '17 at 11:51

After checking further with jconsole, I have seen that a deadlock is created: a thread waits in

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

and another waits in

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)

The problem seems to be that the EAR application comes with its own log4j library, without excluding the one from WildFly. The following part in the jboss-deployment-structure.xml file seems to solve the problem, by 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>

FYI the deadlock is fixed in `org.jboss.logmanager:log4j-jboss-logmanager:1.1.2.Final`. You should just be able to replace the library as no other changes were made. But what you're doing also fixes it and uses the version of log4j supplied in your deployment. — James R. Perkins, Aug 03 '15 at 16:38
Where does the jboss-deployment-structure.xml file need to be? — John, Jun 16 '17 at 19:46

WildFly 8.2.X hangs after REdeployment and gets unreponsive

1 Answers1