[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?

[熊毓华]

Hi~

I am getting the trace data using lttng-live mode via babeltrace2. In the final step, I borrowed the code in doc/api/libbabeltrace2/examples/epitome.c.




The difference is that in print_message(line 172) in function epitome_out_consume, instead of printing the data directly to the console, I send it out using the socket.

Of course, I can get the parsed results, such as timestamp, event->name, etc., through the socket's recv function on the other end.




However, we know that LTTng is continuously generating CTF data, and BabelTrace2 will continuously parse CTF data. Babeltrace2 then continuously sends parsed CTF data over the socket(in my code) or prints it directly to the console(in the example "epitome" given).




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?




I thought I can find the reason in the bt_message_iterator_next function(line 144),but I failed.So I wrote this email hoping to find out why.




Looking forward to your reply.It would be better if you could help me point it out in the code.




thanks,

Yuhua.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20220309/2c541657/attachment.htm>