Alan,
Here is the limit I mentioned:
/**
Returns a pointer to the first writable block on the block chain.
Returns NULL if there are not currently any writable blocks on the
block list.
*/
IOBufferBlock *
first_write_block()
{
if (_writer) {
if (_writer->next && !_writer->write_avail())
return _writer->next;
ink_assert(!_writer->next || !_writer->next->read_avail());
return _writer;
} else
return NULL;
}
first_write_block will look at only the first 2 buffer blocks in the list when
the pointer to the first buffer block is requested. So if you had a chain of
more than 2 buffers in the list and the first 2 were full we do not continue to
iterate through the possible list.
Craig S.
From: Alan Carroll
<[email protected]<mailto:[email protected]>>
Reply-To: Alan Carroll
<[email protected]<mailto:[email protected]>>
Date: Friday, May 27, 2016 at 11:09 AM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: Craig Schomburg <[email protected]<mailto:[email protected]>>
Subject: Re: SSLNetVConnection IOBufferBlock management issue
The IOBufferBlock _end and _start should never be reset to free the buffer
space. The block itself should be released and a new one allocated to store
additional information. The buffer block chain can be of arbitrary length, I
haven't seen anywhere in the code that a max length is presumed. Could you
point out that code? The IOBufferBlocks are treated as write once, stable
blocks of memory so they can be passed along without copying the memory as the
data flows through.
In general would should happen is MIOBuffer::write_avail() should be called and
that will add a new block (if needed) to the writer block chain (see
MIOBuffer::write_avail in iocore/eventsystem/P_IOBuffer.h). Unfortunately I
don't see where that is being done, but we have run 6.2.x in production for
testing and the TLS works. I'll see what I can find.
