Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

JAEGER_REPORTER_MAX_QUEUE_SIZE is not the max queue size #607

Closed
jpkrohling opened this issue Mar 21, 2019 · 0 comments
Closed

JAEGER_REPORTER_MAX_QUEUE_SIZE is not the max queue size #607

jpkrohling opened this issue Mar 21, 2019 · 0 comments

Comments

@jpkrohling
Copy link
Collaborator

jpkrohling commented Mar 21, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants