[lttng-dev] In lttng-live mode, if the printing speed cannot keep up with the generation speed of the parsed ctf data, where will the data be stored?

Jonathan Rajotte-Julien jonathan.rajotte-julien at efficios.com
Tue Mar 8 11:39:01 EST 2022


Hi 

> I wonder if my socket recv function is blocked on the other end, causing the
> socket send function to block in print_message function in babeltrace2;or when
> printing to the console, the printing speed can't keep up with the parsed CTF
> data generation speed and the print buffer is also full.

> In this case, how will Babeltrace2 handle the parsed CTF data that has not been
> sent yet, store them in a buffer, a queue or just discard them? Or would the
> blocking directly cause LTTng to discard the original CTF data at the ring
> buffer before LTTng Consumer daemon?
Not sure I understand your setup but when using lttng-live, you are effectively reading from the data that lttng-relayd is collecting, piece by piece. 
The producing side is not affected by the speed at which the reader (babeltrace2) consume data from lttng-relayd using the lttng-live protocol. 
There might be some corner case here and there but for most base usage of the "live" feature reader (babeltrace2) and producer(lttng/lttng-consumerd) 
are "decoupled". You can consider the "lttng-relayd" (and the trace on the filesystem) as the "buffer" here. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20220308/e431f3b8/attachment.htm>


More information about the lttng-dev mailing list