APR connector crashes after JBoss reload

Solution Verified - Updated

Environment

  • JBoss Enterprise Application Platform (EAP) 6.x

Issue

  • After calling for a reload via the JBoss CLI, we see the JVM crash:
Stack: [0x00007f9055d44000,0x00007f9055e45000],  sp=0x00007f9055e43748,  free space=1021k
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I+0
j  org.apache.coyote.ajp.AjpAprProcessor.process(J)Lorg/apache/tomcat/util/net/AprEndpoint$Handler$SocketState;+123
j  org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(J)Lorg/apache/tomcat/util/net/AprEndpoint$Handler$SocketState;+22
j  org.apache.tomcat.util.net.AprEndpoint$Worker.run()V+167
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

Resolution

  • Avoid doing a reload when using native APR connectors

Root Cause

  • The AprEndpoint destroys the APR serversock pool when it is stopped by the reload, but it doesn't specifically tear down every keepalive connection. Thus prior keepalive connections get to last across the reload in a likely bad state, allowing for a crash when those old connections are reused after the reload. In a conventional shutdown, the lack of that clean up isn't generally concerning since JBoss stops then anyway. But the reload could allow for unaccounted for issues.
  • This content is not included.BZ-1300429
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.