Shizuo Fujita

> However, it took about 80 seconds for the first output, and I'm still unsure if it's correct behavior... This behavior is related to https://docs.fluentd.org/output/exec_filter#example-configuration ``` When using the JSON...

Hmmm Looking at the byte sequence `93 a5 7a 2e 6c 6f 67` as MessagePack, it looks like the data is cut off after `["z.log"` (a 3-element array header +...

Could you please clarify the nature of your 'proprietary log server'? Is it another Fluentd instance running the in_forward plugin, or is it a custom-developed application?

Thank you for clarifying that your log server is a custom application implemented in C++. `out_forward` uses [IO.copy_stream](https://github.com/fluent/fluentd/blob/b4dc14dcdf9169a0224955252b468a365e5fce87/lib/fluent/plugin/out_forward.rb#L687) to flush a log chunk into socket as stream, the TCP protocol...

If possible, can you capture and attach a series of TCP packets? Then, we may find the way to reproduce your issue.

`out_forward` sends the file contents as-is. If the buffer file handled by Fluentd becomes corrupted due to system failure (etc.), corrupted data will be sent. `in_forward` performs a simple check...

hmm. If the file is corrupted, `out_forward` should log something... Looks for me the log you attached does not appear to show any such things...

> I will try to get my hands on a system in the failing state to see what the buffer files look like. If your theory of corrupted files is...

Thanks. It is interesting. I will look and investigate it

seems to be insufficient validation that a gzip-compressed buffer file is corrupted. If you can remove the `compress gzip` configuration, it might make stable... maybe.