it is return to net_read_io() from ssl_read_from_net() when the MIOBuffer
is full for write.
and net_read_io will callback to HttpSM with EVENT_READ_READY to consume
the data in MIOBuffer and reenable ReadVIO.
then do readReschedule() after callback return from HttpSM.
Only read at most 2 blocks, it is limit the memory usage and make every
(include slow & fast) connection has a chance to do read operation.
In a loop, every connection has 2 read operation at most and every
connection only keep 2 IOBufferBlocks memory in a time.
2016-05-28 0:06 GMT+08:00 Craig Schomburg (craigs) <cra...@cisco.com>:
> 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 <solidwallofc...@yahoo-inc.com<mailto:
> solidwallofc...@yahoo-inc.com>>
> Reply-To: Alan Carroll <solidwallofc...@yahoo-inc.com<mailto:
> solidwallofc...@yahoo-inc.com>>
> Date: Friday, May 27, 2016 at 11:09 AM
> To: "dev@trafficserver.apache.org<mailto:dev@trafficserver.apache.org>" <
> dev@trafficserver.apache.org<mailto:dev@trafficserver.apache.org>>
> Cc: Craig Schomburg <cra...@cisco.com<mailto:cra...@cisco.com>>
> 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.
>
>
>
