Fix handshake regression #407
Conversation
bazsi
force-pushed
the
fix-handshake-regression
branch
2 times, most recently
from
f259d45 to
c2cf91f
Compare
Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
bazsi
force-pushed
the
fix-handshake-regression
branch
from
c2cf91f to
a56c0b5
Compare
…OL already With that, our prepare() method will be able to wake us up if we indeed buffered a full line already. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
…t at EOF Previously this case was handled using the complex "immediate_check" logic, which I am about to get rid of. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
This was to force the LogReader instance to immediately start reading once at startup. This is being replaced by poll-fd-events reporting readability if we are at the middle of the file and also by LogProto if we have buffered data. Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>
bazsi
force-pushed
the
fix-handshake-regression
branch
from
a56c0b5 to
0cac6bf
Compare
|
@HofiOne This fixes the restart mechanism without reverting the handshake simplification. I reviewed the changes and everything seems to be fine, but the text-server/buffered-server implementation is complex and it's relatively easy to miss small details during review. Would it be possible to run your internal tests on this PR to double-check for regressions (if you have plans to backport this change, of course)? |
@MrAnno The issue came up during the backport attempt of the simplification, and I'd like to continue it, but
I cannot see now how to resolve this best. I'll surely get back to this, but as far as I can see, it will not be in the near future. Thanks for the signal! |
|
Okay, we move forward then. Thanks. |
This is an alternative solution to #388
The regression happens in the LogReader: #155 causes us to skip a poll iteration because of the handshake (even if it does not exist). This causes a problem as at the very first iteration it is only "immediate_check" that causes us to start fetching messages. And that only fires once. By skipping that first iteration, we stall and stop fetching messages.
Instead of reverting the handshake related change (which should be correct in any async environment), I dropped the immediate_check mechanism (instead of a single internal user that could probably be eliminated) and implemented checking for I/O state in the usual polling paths. Which means: we want to know if there are unprocessed bytes in the file (e.g. poll-file-events), and if there are no bytes there, we want to know if our buffer contains an entire line.
I tried to limit the scope of this change as much as possible.