Fluentd: Remove_newline default must be "false" in in_udp plugin
Remove_newline default must be false not true as in a first place it does not make much sense to remove anything in in_udp.
mpergament
All 6 comments
it breaks existing behaviour so it is hard.
repeatedly
on 14 Nov 2017
Existing behaviour is bad as UDP does not know anything about strings. It is all about bytes and you cannot just remove valid bytes.
mpergament
on 14 Nov 2017
If try to change the default value, we need several months for users.
repeatedly
on 14 Nov 2017
Imho it is also NOT an enhancement request but bug. Well, then it takes what it takes. If it would be me I would just remove it all together (no options). If you go with option it has to be false as a default.
mpergament
on 14 Nov 2017
If you go with option it has to be false as a default.
Yes with several month transitional period.
Again, some users already use in_udp plugin with text transfer and they assume text doesn't have new line of the end in fluentd pipeline.
So don't break this behaviour without transitional period.
repeatedly
on 14 Nov 2017
Just to close this one :). Sure you can go with transition period. My point is rather following:
1) UDP plugin should never ever interpret bytes as string. That is why having an option does not make sense
2) If any users of that plugin rely on removed new line then they definitely do something wrong
3) Current behaviour is not acceptable at all (as valid byte is just removed) and should be fixed asap (and I am wondering how it is possible that nobody hit this issue before to be honest)
mpergament
on 15 Nov 2017
Related issues
JayTeli
路
4Comments
dmnfortytwo
路
3Comments
aleks-mariusz
路
7Comments
repeatedly
路
7Comments
pdecat
路
7Comments
Most helpful comment
Just to close this one :). Sure you can go with transition period. My point is rather following:
1) UDP plugin should never ever interpret bytes as string. That is why having an option does not make sense
2) If any users of that plugin rely on removed new line then they definitely do something wrong
3) Current behaviour is not acceptable at all (as valid byte is just removed) and should be fixed asap (and I am wondering how it is possible that nobody hit this issue before to be honest)