-
Notifications
You must be signed in to change notification settings - Fork 131
Frequent EMSGSIZE with UDPSender #124
Comments
Could you provide more details?
|
That sounds like incorrect calculation of the cumulative message size, which is a somewhat tricky problem with thrift and compact encoding. The max packet size should not be fiddled with because it's what the agent expects, it will not accept different sizes. |
I reproduce this problem using jaeger-client@3.5.3, form Mac OS, MTU: 1500, node version: 8.3 like: this._client.send(thriftBuffer, 0, thriftBuffer.length, this._port, this._host, function(e, sent) {
if (e) {
console.log("thriftBuffer.length: ", thriftBuffer.length)
console.log("sent: ", sent)
console.log(e)
}
});
this._client.on('error', err => {
console.log(`error sending span: ${err}`)
}) this code can not get this error, so the error should from: not sure why called btw, Im using https://github.com/RisingStack/jaeger-node now, author is @hekike , so Im not sure the issue is because of RisingStack/jaeger-node or uber/jaeger-client-node. and, https://github.com/uber/jaeger-client-node/blob/master/src/reporters/udp_sender.js#L29 |
@zhongfox are you running the agent on the same host? UDP packets on loopback interface can be up to 64Kb without fragmentation, which is why we have |
@yurishkuro yes, agent and node project are in the same mac pro.
looks like my LOOPBACK mtu is 16384, should it be 65000? but even I change to I can still get this error:
from some sources, EMSGSIZE indicate the data which application send is bigger than udp socket buffer, which can be changed by SO_SENDBUF, but seem node.js dgram doesn't provide such api. |
My Mac also has mtu 16384 for loopback. But also this:
maybe you try increasing these, or limiting jaeger client to these sizes. In contrast, on a Linux host:
|
turn out mac https://stackoverflow.com/questions/9123098/set-max-packet-size-for-gcdasyncudpsocket so this code aways fail in my mac var dgram = require('dgram');
var message = new Buffer(9217); // 9216 or smaller is ok
var client = dgram.createSocket("udp4");
client.send(message, 0, message.length, 6832, "localhost", function(err) {
console.log(message.length)
console.log(err)
client.close();
}); so I did this:
the problem solved. |
@yurishkuro |
I believe this has been solved. Please reopen if not. |
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
UDP packets cannot exceed MTU. If they do, the app gets {error,emsgsize} from gen_udp:send. Similar issue: jaegertracing/jaeger-client-node#124 This commit adds packet size check. Packets are sent immediately upon reaching max size, even before the end of batch window. Size calculation from CollectedMetrics map would've been costly. I changed the format to binary. Metrics are encoded into Line Protocol immediately now, instead of right before sending. This also helps avoid data loss. The map did not record all timestamps. It set the most recent timestamp for all fields of the same measurement. It also did not honor differences in tags, but I guess there aren't any when metrics go through Exometer.
Change return type "unknow" to HttpTextFormat for getHttpTextFormat Change return type "unknow" to BinaryFormat for getBinaryFormat Close jaegertracing#124 jaegertracing#123 Signed-off-by: Olivier Albertini <olivier.albertini@montreal.ca>
I run frequently into
EMSGSIZE
error withUDPSender
sender.I tried to configure a huge
maxPacketSize
without any luck.Do you experience similar issue?
The text was updated successfully, but these errors were encountered: