Add multiline support to TCP

[sumo-drosiek]

This is my proposal for multiline support in TCP
It's not finished yet, but please see if this is acceptable direction

• moving encoding and multiline to helper to reuse it in TCP
• create reader for TCP input operator

[sumo-drosiek]

Sorry for the quality, but I want to get feedback of general idea quickly to resume work on that Tomorrow

[djaglowski]

@sumo-drosiek, Thanks for taking a crack at this.

I agree with moving encoding and multiline to helper. I may have some minor comments later, but overall this looks great.

However, I don't see the value of the Reader. Can we just enhance goHandleMessages to make use of encoding and multiline? Maybe I am missing something, but this seems like an unnecessary abstraction.

[djaglowski]

This looks great. Thanks @sumo-drosiek!

[sumo-drosiek]

I change multiline to return splitFunc directly and renamed MaxBufferSize to MaxLogSize

[sumo-drosiek]

ready to go 🎉

[djaglowski]

@sumo-drosiek This looks great, but somehow the EasyCLA check is hung. I can't merge until is passes, and I don't see a way to retrigger it from my end. Will you please push a trivial commit in order to retrigger it?

[sumo-drosiek]

@djaglowski I noticed that I use encoder only during splitting messages. I need to use it in decoding messages as well. Due to that encoder helper will be probably changed (extended with decode method)

[sumo-drosiek]

I create it every call to avoid race conditions
I left file reader implementation in file operator because it's optimized for that usecase

[djaglowski]

Seems reasonable. If it proves to be a performance bottleneck at some point, we can look at optimizing then.

[sumo-drosiek]

@djaglowski Please see latest commit and I think we are good to go :)

[djaglowski]

LGTM

[djaglowski]

Seems reasonable. If it proves to be a performance bottleneck at some point, we can look at optimizing then.