Team A
[ZBX-15138] Uncompressed message warning shows expected_len instead of reserved Created: 2018 Nov 07 Updated: 2024 Apr 10 Resolved: 2018 Nov 15 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Agent (G), Proxy (P), Server (S) |
| Affects Version/s: | 4.0.1 |
| Fix Version/s: | 4.0.2rc1, 4.2.0alpha1, 4.2 (plan) |
| Type: | Patch request | Priority: | Trivial |
| Reporter: | Grant Ashton | Assignee: | Alex Kalimulin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Team: | Team A |
| Sprint: | Sprint 46, Nov 2018 |
| Story Points: | 0.125 |
| Description |
|
8027:20181106:232953.095 Uncompressed message size 6902047 from hostA exceeds the maximum size 134217728 bytes. Message ignored. This message does not make sense, and the reason for that is it is showing the expected_len instead of the reserved size, which it is actually checking, retrieved from the PDU to indicate the size of the compressed data uncompressed. Looks like an honest copy and paste bug from the uncompressed section above it, where it does compare ZBX_MAX_RECV_DATA_SIZE to expected_len. [https://github.com/zabbix/zabbix/blob/trunk/src/libs/zbxcomms/comms.c|Lines 1664 - 1673] /* compressed protocol stores uncompressed packet size in the reserved data */ if (0 != (protocol_version & ZBX_TCP_COMPRESS) && ZBX_MAX_RECV_DATA_SIZE < reserved) |
| Comments |
| Comment by Vladislavs Sokurenko [ 2018 Nov 07 ] |
|
Thank you for your report, yes error message should be fixed
Index: src/libs/zbxcomms/comms.c
===================================================================
--- src/libs/zbxcomms/comms.c (revision 86544)
+++ src/libs/zbxcomms/comms.c (working copy)
@@ -1666,7 +1666,7 @@
{
zabbix_log(LOG_LEVEL_WARNING, "Uncompressed message size " ZBX_FS_UI64
" from %s exceeds the maximum size " ZBX_FS_UI64
- " bytes. Message ignored.", (zbx_uint64_t)expected_len,
+ " bytes. Message ignored.", (zbx_uint64_t)reserved,
s->peer, (zbx_uint64_t)ZBX_MAX_RECV_DATA_SIZE);
nbytes = ZBX_PROTO_ERROR;
goto out;
|
| Comment by Grant Ashton [ 2018 Nov 07 ] |
|
Thanks! Is there a reason there is a 128 MiB limit on uncompressed data per TCP connection? As we have a large config 700,000 items, 600 hosts. Which are being polled from a single Proxy, and the config can't be downloaded because of this. The proxy is able to handle the estimated 1400 VPS, if it could get the config. There doesn't seem to be an option to fragment the config either to overcome this limitation. Compression (which reduces it to ~7MB) doesn't help either as that section of code checks the uncompressed data size. |
| Comment by Vladislavs Sokurenko [ 2018 Nov 07 ] |
|
I believe the reason is not to overload Zabbix server, it should be safe to increase in your case. |
| Comment by Glebs Ivanovskis [ 2018 Nov 07 ] |
|
Related issue Index: trunk/include/common.h =================================================================== --- trunk/include/common.h (revision 43681) +++ trunk/include/common.h (revision 43682) @@ -893,7 +893,7 @@ #define ZBX_JAN_2038 2145916800 #define ZBX_JAN_1970_IN_SEC 2208988800.0 /* 1970 - 1900 in seconds */ -#define ZBX_MAX_RECV_DATA_SIZE (64 * ZBX_MEBIBYTE) +#define ZBX_MAX_RECV_DATA_SIZE (128 * ZBX_MEBIBYTE) /* max length of base64 data */ #define ZBX_MAX_B64_LEN (16 * ZBX_KIBIBYTE) Because, obviously, 128 MB ought to be enough for anybody! Back then there was a very reasonable question asked by okkuv9xh. But I could not find a relevant feature request. |
