Fix line skipping issue in receive_lines method

[yugeeklab]

Which issue(s) this PR fixes:
Fixes #4494

What this PR does / why we need it:
Before this patch, long lines could cause breakdowns in fluentd, potentially posing a vulnerability. With this patch, max_line_size will be integrated into the FIFO, enabling the system to skip lines exceeding the maximum size before executing receive_lines.

Docs Changes:

Release Note:

[daipom]

@yugeeklab Thanks for this fix!
CI is currently unstable because of #4487. We will fix it. Sorry for the trouble.

I see the intent of this fix as follows.

• In the current implementation, large lines that would eventually be discarded in receive_lines are temporarily held in IOHandler's @lines.
• This is a waste of memory.
• This PR resolves the waste.

Surely, such a fix would allow us to limit memory consumption by the max_line_size setting to some extent!

This PR would be effective to some extent, however I believe the problem of memory consumption will remain.
It would be possible that FIFO's @buffer becomes unlimitedly large if the @eol does not appear in the data.

Are these my understandings correct?

[yugeeklab]

Hi, @daipom

I've just published an issue #4491 for more information.

This PR would be effective to some extent, however I believe the problem of memory consumption will remain.
It would be possible that FIFO's @buffer becomes unlimitedly large if the @EOL does not appear in the data.

When max_line_size isn't set, FIFO's @buffer can grow indefinitely. Or if max_line_size has large value, FIFO's buffer will be limited, but there's still a possibility of fluentd experiencing slowdowns.

Summary:

as-is: max_line_size helps you avoid buffer overflow configuring via buffer section.
to-be: max_line_size helps prevent buffer overflow by configuring the buffer section and also ensures FIFO's buffer size remains limited.

If you have any suggestions, such as the fifo_buffer_size parameter or any other ideas, please feel free to discuss them with me.

Thank you for your review!

[daipom]

@yugeeklab

I've just published an issue #4491 for more information.

Thanks so much!

as-is: max_line_size helps you avoid buffer overflow configuring via buffer section. to-be: max_line_size helps prevent buffer overflow by configuring the buffer section and also ensures FIFO's buffer size remains limited.

Now I understand!
The following understanding was not correct.

This PR would be effective to some extent, however I believe the problem of memory consumption will remain.
It would be possible that FIFO's @buffer becomes unlimitedly large if the @eol does not appear in the data.

This fix clears FIFO's @buffer when read_lines.
So, this fix ensures FIFO's buffer size remains limited.

If you have any suggestions, such as the fifo_buffer_size parameter or any other ideas, please feel free to discuss them with me.

Thanks!
Basically, it seems to be a very good idea to limit the FIFO's buffer.

[yugeeklab]

Basically, it seems to be a very good idea to limit the FIFO's buffer.

Thank you for your comment!! @daipom

Please let me know if there's any feedback on my code or idea. I'll review and accept your feedback as soon as possible.

Thank you.

[daipom]

About CI failures, although #4493 has been resolved, we still need to resolve #4487.

[daipom]

@yugeeklab The CI issue has been resolved. Sorry for the trouble.
Could you please rebase this branch on the latest master?

[yugeeklab]

Hi, @daipom

Rebase is done!!

Thank you for your review!!

[daipom]

Sorry for waiting.
I will review this soon.

[daipom]

@yugeeklab Thanks for this fix!
This fix basically looks good to me!
I've commented on some minor details (about the following), please check!

• Keeping the same debug log as before
• Improving codes
• Improving tests

[daipom]

@yugeeklab
Thanks for updating.
I'm checking the CI failures.

[daipom]

Current CI failures have nothing to do with this PR.
Sorry for the trouble again.

[daipom]

The CI issue has been resolved.
So, could you please rebase this to the latest master?
Sorry for the trouble again.

[yugeeklab]

Hi, @daipom

Rebase is done.
I also added a commit to resolve the following issue.
Please review it if you don't mind.

Thank you.

[daipom]

Thanks for the fix!
The following point is a remaining concern.

#4491 (comment)

I saw bf73efe and realized that there is a problem that needs to be solved about the management of pos

We should not update pos like this commit (bf73efe).
We should only update pos at points where recovery is possible.
This means that we should not update pos until we can be sure that @lines has been successfully handled by @receive_lines.
If updating pos like this commit, some data may be lost when BufferOverflowError occurs or when Fluentd is forced to stop.
(see #4491 (comment))

So, we need to consider how to manage pos correctly for this feature.
It needs to be able to continue processing correctly even if Fluentd is forced to stop.
Repeating process to skip long lines would be acceptable.
Data loss or sending corrupted data would be unacceptable.

For this feature, we need to take care of @was_long_line in particular.
We need to make sure that the restart of Fluentd does not cause a subsequent incomplete log to be sent.

[daipom]

We should not update pos like this commit (bf73efe).
...
If updating pos like this commit, some data may be lost when BufferOverflowError occurs or when Fluentd is forced to stop.

Oh, sorry, it was wrong.
The @lines.empty? condition will prevent it (probably...).

fluentd/lib/fluent/plugin/in_tail.rb

Lines 1230 to 1232 in bf73efe

	if @lines.empty? && has_skipped_line
	@watcher.pe.update_pos(io.pos - @fifo.bytesize)
	end

So, we need to consider only the following points.

For this feature, we need to take care of @was_long_line in particular.
We need to make sure that the restart of Fluentd does not cause a subsequent incomplete log to be sent.

[daipom]

Is there any reason why keeping @has_skipped_line as an instance variable?
If it is not necessary to keep it, we should make it the local variable in read_lines() and make read_lines() return it as a returning value.

[daipom]

Please see #4491 (comment).

make has_skipped_line local variable is for this.

[daipom]

So, we need to consider only the following points.

For this feature, we need to take care of @was_long_line in particular.
We need to make sure that the restart of Fluentd does not cause a subsequent incomplete log to be sent.

I think we should change FIFO#bytesize.

fluentd/lib/fluent/plugin/in_tail.rb

Lines 1087 to 1089 in bf73efe

	def bytesize
	@buffer.bytesize
	end

It is used in the following pos logic:

fluentd/lib/fluent/plugin/in_tail.rb

Lines 1230 to 1241 in bf73efe

	if @lines.empty? && has_skipped_line
	@watcher.pe.update_pos(io.pos - @fifo.bytesize)
	end
	unless @lines.empty?
	if @receive_lines.call(@lines, @watcher)
	@watcher.pe.update_pos(io.pos - @fifo.bytesize)
	@lines.clear
	else
	read_more = false
	end
	end

fluentd/lib/fluent/plugin/in_tail.rb

Lines 1246 to 1248 in bf73efe

	def open
	io = Fluent::FileWrapper.open(@path)
	io.seek(@watcher.pe.read_pos + @fifo.bytesize)

The bytesize should be the uncommitted byte size that FIFO is still handling.
It does not equal the size of the buffer of FIFO anymore because FIFO can clear the buffer to skip the long line.

In the following case (max_line_size 12), very long line not finished yet will be cleared from the buffer soon.

short line\n # To be committed to the pos
very long line not finished yet # Not to be committed to the pos until the `@eol` occurs.

However, that data size should be considered for pos handling.
Since the line is not finished yet, the pos update should be done up to the end of short line\n.
(When Fluentd restarts, Fluentd should continue the process from the end of short line\n.)
Also, the reopening pos should be from the end of very long line not finished yet (especially for the case open_on_every_update).

For this, FIFO#bytesize should be the uncommitted byte size that FIFO is still handling, not the real buffer size of FIFO.

[daipom]

@yugeeklab I have fixed the remaining points and pushed them to my tmp branch (the following 3 commits).
Could you please check them?
If there is no problem, I will push these commits to this PR.
If you have any concerns or ideas, please let me know.

• https://github.com/daipom/fluentd/tree/in_tail-improve-max_line_size
  • make has_skipped_line local variable
  • refactor some variable names
  • fix to commit the correct pos to continue processing correctly

The main point is to resolve the issue that is tested on the 'discards a subsequent data in a long line even if restarting occurs between' test in fix to commit the correct pos to continue processing correctly.
This test would fail in the current branch.