I'm making a tuning guide for Jaeger and, checking the code for the JAEGER_REPORTER_MAX_QUEUE_SIZE setting I realized that this does not represent the number of spans in memory to be kept before they are sent out, as the documentation makes me believe:
defines the max size of the in-memory buffer used to keep spans before they are sent out.
Rather, it's a command queue size, where each span is added to an AppendCommand. This command calls the Sender#append() method which in most cases will just add the span to the Sender's own buffer. If the max packet size for the sender is reached, the #append() command will block until the packet is sent. In most cases, though, a periodic timer will call #flush(), which generates a FlushCommand and puts in the same queue as the AppendCommand.
This means that there might be far more than 100 spans in memory, as there might be, say, 50 FlushCommand being executed waiting for the server to return (feasible in case of HttpSender, not so much for UdpSender). Given that the internal HttpSender buffer defaults to 1 MB, this scenario presents 50 MB worth of spans.
I'm not sure there's an action item about this: if we have long term plans for the Java Client, we might consider rewriting the whole reporter/sender part when we add gRPC support. In any case, I thought it's good to have this documented somewhere.
The text was updated successfully, but these errors were encountered: