This demo proves the memory retention model:
[kept messages][rotating tail]
The demo keeps the first 3 messages forever and rotates only the later tail.
From the project root:
make demoThat gives you:
target/debug/ljdtarget/debug/otlp-bofh-emittertarget/debug/otlp-demo-collectortarget/debug/otlp-wire-forwarder
From this directory:
./run-demo.shThe script:
- starts
ljdin memory mode with:buffer.keep: 3buffer.messages: 10
- emits 10 startup messages:
this message #1 must be kept- ...
this message #10 must be kept
- emits 100 BOFH flood messages with no delay
- starts the OTLP collector mockup
- connects a wire forwarder to
ljdreplay - forwards exactly 13 messages to the collector
Expected result:
- the collector shows:
- the first 3 startup messages
- the last 10 flood messages
- startup messages
#4through#10are gone
- kept front jar: 3
- rotating tail: 10
- total retained after the late consumer connects: 13
- ingest is OTLP/HTTP on
127.0.0.1:4318 - replay listener is the internal wire protocol on
127.0.0.1:7002 - collector mockup listens on
127.0.0.1:4320 - this demo is intentionally deterministic
If you want a smaller visible run where startup messages #4 through #10 are
still present together with a few BOFH messages, run:
./run-demo-memshow.shThis variant uses:
buffer.keep: 3- total visible ring of 15 messages
- rotating tail size of 12 messages
- 10 startup messages
- 5 BOFH flood messages
Expected result:
- you see the first 3 startup messages
- you see startup messages
#4through#10 - you see 5 BOFH flood messages
Total retained and forwarded:
- kept front jar: 3
- rotating tail: 12
- total shown: 15
Why the config says buffer.messages: 12:
- in
ljd,buffer.messagesapplies only to the rotating tail - the first 3 kept messages are outside that limit
- so
3 kept + 12 tail = 15 total visible messages