Details
-
Bug
-
Resolution: Done
-
Major
-
1.3.24.Final, 1.4.0.Final
-
None
Description
At load with WebSockets on SSL, we have been seeing IllegalStateException
exceptions which we suspect are due to dirty connection closes. The
observed stack in 1.3.23.Final is:
[org.xnio.nio] (default I/O-15) XNIO000011: Task io.undertow.protocols.ssl.SslConduit$1@959ab9 failed with an exception: java.lang.IllegalStateException: UT000091: Buffer has already been freed
at io.undertow.server.DefaultByteBufferPool$DefaultPooledBuffer.getBuffer(DefaultByteBufferPool.java:196)
at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:744)
at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:603)
at io.undertow.protocols.ssl.SslConduit.access$500(SslConduit.java:63)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1029)
at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:225)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
If past the this.unwrappedData = unwrappedData; call on about 753,
the class-level unwrappedData is the same as the stack instance. After
that point, any RuntimeException or IOException will result in a call
to this.unwrappedData.close() via close()->closed(). As a result, this
exception case will always call unwrappedData.getBuffer() on a closed
PooledByteBuffer and throw the IllegalStateException. Since this is
thrown from the finally block, it will mask the original exception.
I've been unable to reproduce this locally, but this seems like a
potential issue that should be fixed. I also don't see another
case where unwrappedData is non-null and non-open.
Attachments
Issue Links
- is cloned by
-
-
- Verified
-
-
-
- Verified
-
