I'm only raising this manually for documentation:
Spring currently configures the Brave AsyncSpanHandler with default settings. These defaults included 3 thresholds to flush a backlog, whichever comes first.
The estimated size in bytes threshold (queuedMaxBytes=1pct memory) has been disabled by default and deprecated, due to appearing pinned when virtual threads are in use (-Djdk.tracePinnedThreads). This is effectively no impact due to the other two flush thresholds (queuedMaxSpans=10000,messageTimeout=1s), most importantly that in the default case (such as spring-boot not setting anything), you are much more likely to hit 1s timeout prior to 1pct of memory of 10k spans.
See https://github.com/openzipkin/zipkin-reporter-java/releases/tag/3.4.0 for more
Trivia time
OpenTelemetry's defaults are also in use in BatchSpanProcessorBuilder. There is no queuedMaxBytes analogue in their setup (in hindsight a good thing probably).
* otel maxQueueSize=2048 vs zipkin-reporter queuedMaxSpans=10000
* otel scheduleDelay=5s vs zipkin-reporter messageTimeout=1s
My unsolicited 2p is that the maxQueueSize=2048 while arbitrary is better than the queuedMaxSpans=10000 in zipkin-reporter.. I thought it was 10 year old from original brave, but that was 500 🤷. I raised this issue as 2048 is good, even if maybe smaller could be better.
scheduleDelay=5s might not be a great default though. I do remember changing zipkin-reporter to messageTimeout=1s, as beginning devs are impatient and wondered what was wrong prior to 5s :p
Comment From: wilkinsona
This may have to wait for Boot 3.4 depending on whether the observability team want to upgrade to a new minor post RC1.
Comment From: codefromthecrypt
hah maybe I over-explained and doomed it ;)
Comment From: wilkinsona
The observability team have merged the upgrades on their side. We're good to go here.