Hi again Janusz,
On Mon, Apr 11, 2016 at 12:58:08PM +0200, Willy Tarreau wrote:
> Thanks Janusz. I've looked at the code this week-end in 1.5 and am
> having doubts about certain points. I need to compare with 1.6 and
> see whether there are different assumptions in 1.5 than in 1.6
> regarding the buffer length controls.
Now I'm pretty sure about 2 things :
- 1.5 and 1.6 are functionally identical in the way they compute
the amount of data that can be read, so I think you should face
the same issue with 1.5 ;
- the implemented algorithm matches the comments but I don't agree
anymore with the algorithm described in the comment ; I *think*
it forgets to subtract the amount of outgoing data (buf->o) from
the reserve, which channel_full() does subtract. And the code
before the patch used to (though incorrectly).
If the second claim above is right (still to be validated, these
functions take care of a large number of complex cases at once), then
I suspect it might be possible that channel_full() returns "not-full"
meaning "please do poll again I have some room left" and that
buffer_max_len() returns "no room left". In this case I'd predict
that the situation could arise when the buffer is not full but steps
on the reserve and buf->o is present and at least as large as the
reserve.
I'm still on it, depending on my findings, I'll either retire my
claim above and restart digging from scratch, or will propose a
patch to test. If both you and Nenad have a chance to test it and
the problem does not appear anymore, I guess we'll finally declare
a success.
Stay tuned,
Willy
