-
Bug
-
Resolution: Done
-
Major
-
None
-
False
-
None
-
False
-
-
-
-
-
-
-
-
-
The TCP connection is closed from remote EJB server side before an EJB client receives a response under the following conditions:
- The remote EJB request processing takes longer than jboss-remoting HEARTBEAT interval (default: 60000 ms)
- Undertow write-timeout is set shorter than jboss-remoting HEARTBEAT.
When this issue happens, the standalone EJB client will show the following stack trace in the console:
Exception in thread "main" javax.ejb.EJBException: java.nio.channels.ClosedChannelException at org.jboss.ejb.protocol.remote.EJBClientChannel$MethodInvocation.handleClosed(EJBClientChannel.java:1287) at org.jboss.remoting3.util.InvocationTracker.connectionClosed(InvocationTracker.java:222) at org.jboss.remoting3.util.InvocationTracker.lambda$new$0(InvocationTracker.java:70) at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:50) at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:520) at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:425) at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:286) at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:510) at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:368) at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:623) at org.jboss.remoting3.remote.RemoteConnectionHandler.receiveCloseRequest(RemoteConnectionHandler.java:226) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:97) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:51) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) Caused by: java.nio.channels.ClosedChannelException ... 17 more
I suspect the root cause is the same as JBEAP-24358. However, this issue is reproduced with jboss-remoting, not a servlet request. I filed this issue so that QE scenarios with jboss-remoting will also be covered when JBEAP-24358 is fixed.
Unlike HTTP and AJP, a remote EJB server returns a MESSAGE_CLOSE message in the remoting protocol when an entire remote request message is received from client-side. The write-timeout timer starts when the Remote EJB request is received.
After 60 seconds have elapsed from the request being received, a remoting HEARTBEAT message is sent by the EJB client side. Then, the EJB server sends a CONNECTION_ALIVE_ACK as an ack to HEARTBEAT, but closes the TCP connection immediately afterward. When the EJB server writes the ack to HEARTBEAT, undertow write-timeout has already been exceeded, so the TCP connection is closed from the server side without waiting for the remote EJB processing to complete. As a result, no remote EJB response is returned to the client.
- clones
-
JBEAP-24842 [GSS](7.4.z) UNDERTOW-2228 - Undertow write-timeout can cause a closing TCP connection without response for long-running remote EJB request
- Closed
- is cloned by
-
UNDERTOW-2228 [GSS](7.4.z) Undertow write-timeout can cause a truncate response for request coming through keep-alive connection
- Resolved