<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Hi<br></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<p>
<span style="font-size:14px;white-space:normal">I wonder if my socket recv function is blocked on the other end, causing the socket send function to block in <span style="color:#0550ae;font-family:'ui-monospace' , 'sfmono-regular' , 'sf mono' , 'menlo' , 'consolas' , 'liberation mono' , monospace;font-size:12px;white-space:pre;background-color:#ffffff">print_message </span>function in babeltrace2;or when printing to the console, the printing speed can't keep up with the <span style="font-size:14px;white-space:normal">parsed CTF </span>data generation speed and the print buffer is also full.</span>
</p>
<p>
<span style="font-size:14px">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?</span></p></blockquote><div><br></div><div>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. </div><div>The producing side is not affected by the speed at which the reader (babeltrace2) consume data from lttng-relayd using the lttng-live protocol.</div><div> 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)</div><div> are "decoupled". You can consider the "lttng-relayd" (and the trace on the filesystem) as the "buffer" here.</div></div></div></body></html>