Hey folks,
We are encountering a SSLVNetConnection IOBufferBlock buffer management
issue in ATS 6.0.0 that we did not see in the earlier ATS 4.0.1 release
Which we were using.
What we see in ssl_read_from_net() is when we get multiple GET requests on
a single SSL session, as each GET is processed and ACK/NACK’ed that the
buffer is not reset and the space released for reuse. As a result, the
available write_avail() space in the session IOBufferBlock buffer is
reduced with each subsequent packet until we have insufficient space to
buffer the packet.
Also appears that ATS is set up to support a chain of 2 IOBufferBlock
but since only 1 is allocated we bail out of the read loop in
ssl_read_from_net() with a incomplete packet and then drop it.
Request Response Txn-ID VC
---------------------------- ---------------- ------ --------------
GET /call/187972?debug=1 200 OK 4 0x560bb93e6420
b->write_avail()=4096, nread=0
b->write_avail()=4096, nread=1900 (2196 left in buffer)
nread=0 PARSE DONE
GET /call/widget.jsp... 200 OK 5 0x560bb93e6420
b->write_avail()=2196, nread=0
b->write_avail()=2196, nread=2120 ( 76 left in buffer)
nread=0 PARSE DONE
GET /call/js/libs/require.js 304 Not Modified 6 0x560bb93e6420
b->write_avail()=76, nread=0
b->write_avail()=76, nread=76 ( 0 left)
b->next is NULL so ssl_read_from_net() bails on read loop and remainder
of packet is not read
We hacked the ssl_read_from_net() code in the SSL_ERROR_NONE case to
add_block() if b->next == NULL and block_write_avail == 0 and that
“appeared” to get us working again but I am not convinced that was the
correct solution. Concerned because it appears that other areas of the
code assume there will never be more than 2 buffers in the list and we
did not put a limit on the list length.
So my question is when should the IOBufferBlock _end and _start have
been reset() to free the buffer space? I assumed that since we were seeing
a serial Packet(GET), ACK, Packet(GET), ACK, Packet(GET), ACK, that the
Buffer space could/should have been reset after each ACK?
Also curious if this is a known issue with ATS 6.0.0 that has been
addressed or is known/unaddressed?
Continuing to dig through the code in the mean time. Any feedback, insight,
etc. would be appreciated…
Thanks,
Craig S.
