-
Bug
-
Resolution: Done
-
Major
-
4.0.24.Final
-
None
Recently added line
IoUtils.safeShutdownReads(remoteConnection.getChannel());
in RemoteConnectionHandler.closeAction() swallows IOException, preventing the handler from being marked as closed, which can lead to a client hang.
protected void closeAction() throws IOException { sendCloseRequest(); remoteConnection.shutdownWrites(); IoUtils.safeShutdownReads(remoteConnection.getChannel()); // now these guys can't send useless messages closePendingChannels(); closeAllChannels(); remoteConnection.getRemoteConnectionProvider().removeConnectionHandler(this); }
Additionally, AbstractHandleableCloseable.closeAsync() doesn't mark resource as closed in case when Exception other than IOException is thrown in closeAction() method. AbstractHandleableCloseable.close() does so. This is causing client hang too.
public void closeAsync() { ... if (first) try { closeAction(); } catch (IOException e) { log.tracef(e, "Close of %s failed", this); final Map<Key, CloseHandler<? super T>> closeHandlers; synchronized (closeLock) { state = State.CLOSED; closeHandlers = this.closeHandlers; this.closeHandlers = null; closeLock.notifyAll(); } if (closeHandlers != null) { for (final CloseHandler<? super T> handler : closeHandlers.values()) { runCloseTask(new CloseHandlerTask(handler, e)); } } } catch (Throwable t) { log.errorf(t, "Close action for %s failed to execute (resource may be left in an indeterminate state)", this); // -- here non async version marks resource as closed too -- } }
- causes
-
JBEAP-12105 [GSS](7.0.z) [Remoting] SSL EJB Client stuck in AbstractHandleableCloseable.close with shortlived clients and when server is disconnected from network - part 2
- Closed
- is cloned by
-
JBEAP-13162 (7.2.0) REM3-300 Fix exception handling in RemoteConnectionHandler
- Resolved
-
JBEAP-13160 (7.1.0) REM3-300 Fix exception handling in RemoteConnectionHandler
- Closed