Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #10991] Stream buffer size is 512 bytes, could be raised #3859
This issue has been migrated from Redmine: https://dev.icinga.com/issues/10991
Created by tgelf on 2016-01-20 12:40:56 +00:00
I examined this on the REST API, but looks as this affects all streams: Icinga2 is read/writing packets in chunks limited to 512 bytes. That's usually not enough to fit a single check result, so multiple packets are sent over the wire. Via REST it also seems that the newline characters are are sent in a single chunk, so when streaming as a client I basically get a single check result in three packets: 507 bytes, 229 bytes and 1 byte.
Updated by jflach on 2016-01-21 09:59:14 +00:00
No way, the Chinese are never going to approve of that!
On a serious note:
Updated by tgelf on 2016-01-21 12:58:28 +00:00
I'd suggest to stay somewhere around 1280, that would make sure that most chunks fit in single TCP packets even with multiple nesting layers involved, think of PPPoE plus nested VPNs or whatever. ISDN could probably still be forced to split those chunks in multiple packets, but hey - it's 2016.
Regarding the newline: I used the stream REST API, that ships endless JSON strings separated by newline characters. I guess Icinga2 is shipping my multiple chunks for the JSON strings and separate chunks for all those newline separators, but there could of course also something be wrong in my code at the receiving side.