I have configured SSL connection between Wildfly 10.1.0.Final server and a client application using jboss-naming-client to connect to EJB beans. It works fine. If one kills the server process, the client notices that by means of an exception :

2017-04-27 12:59:27,979 Remoting "config-based-naming-client-endpoint" I/O-1 ERROR org.jboss.remoting.remote.connection - JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
2017-04-27 12:59:27,985 Remoting "config-based-naming-client-endpoint" task-11 INFO org.jboss.ejb.client.remoting - EJBCLIENT000016: Channel Channel ID fde0ef25 (outbound) of Remoting connection 5f945bcb to localhost/127.0.0.1:8543 can no longer process messages
Exception in thread "Remoting "config-based-naming-client-endpoint" task-10" 2017-04-27 12:59:27,989 Remoting "config-based-naming-client-endpoint" I/O-1 ERROR org.xnio.listener - XNIO001007: A channel event listener threw an exception
java.lang.IllegalStateException: XNIO000017: Buffer was already freed
at org.xnio.ByteBufferSlicePool$PooledByteBuffer.getResource(ByteBufferSlicePool.java:213)
at org.xnio.ByteBufferSlicePool$PooledByteBuffer.getResource(ByteBufferSlicePool.java:183)
at org.xnio.ssl.JsseSslConduitEngine.wrapCloseMessage(JsseSslConduitEngine.java:814)
at org.xnio.ssl.JsseSslConduitEngine.flush(JsseSslConduitEngine.java:779)
at org.xnio.ssl.JsseSslStreamSinkConduit.flush(JsseSslStreamSinkConduit.java:190)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at org.xnio.channels.AssembledStreamChannel.flush(AssembledStreamChannel.java:201)
at org.xnio.channels.TranslatingSuspendableChannel.flush(TranslatingSuspendableChannel.java:638)
at org.jboss.remoting3.remote.RemoteConnection$RemoteWriteListener.shutdownWrites(RemoteConnection.java:259)
at org.jboss.remoting3.remote.RemoteConnection.shutdownWrites(RemoteConnection.java:128)
at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:111)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:390)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
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:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)

If the client attempts to call anything on server, it gets blocked up (because "invocation.timeout" is zero), while in case of a plain (no-ssl) connection the client detects the server disconnection and attempts to reconnect gracefully.

It looks like the unexpected exception IllegalStateException breaks the internal logic of JsseSslConduitEngine and prevents it from closing up the connection.

I would suggest either to process the exception (wrap it into IOException), or to check the availability of the buffer before sending a close message.