Hi, > I ran my test with the new changes and it seems to improve the lossiness but > not > eliminate it. For example it seems in the hello world example that if the > application exits too quickly after emitting the tracepoint, we might still > lose some events in the consumer even though they are present in the relayd > output folder.
Here by consumer you mean a "live reader" right? If so I would suggest you use the term "live consumer reader" or "live reader" since "consumer" alone can yield some confusion with lttng-consumerd. I would need a reproducer for this, you can base yourself on the reproducer in the commit message for the previous fix. AFAIK there is no valid reason for this to happen, at least based on my review of the code for the fix we just merged. (This is only valid for per-uid tracing, per-pid tracing and lttng live have not so minor limitation inherent to the current lttng-live implementation) > I don't quite understand why that is. Would love some explanations on the > various timing windows where we have a potential to lose the events on the > consumer side. >From a live reader perspective, in per-uid mode, there should be no "loss" of >event from the moment the viewer is attached and the moment it detach. Here "loss" mean that the events are present in the trace gathered by lttng-relayd but not by the live reader for the same "time window". This is only valid if the viewer is not "late" and have consumed everything at the moment it detach. Cheers ----- Original Message ----- > From: "Eqbal" <eqbal...@gmail.com> > To: "Jonathan Rajotte-Julien" <jonathan.rajotte-jul...@efficios.com> > Cc: "lttng-dev" <lttng-dev@lists.lttng.org> > Sent: Monday, May 10, 2021 8:35:41 PM > Subject: Re: [lttng-dev] lttng live event loss with babeltrace2 Hi, > I ran my test with the new changes and it seems to improve the lossiness but > not > eliminate it. For example it seems in the hello world example that if the > application exits too quickly after emitting the tracepoint, we might still > lose some events in the consumer even though they are present in the relayd > output folder. Here by consumer you mean a "live reader" right? If so I would suggest you use the term "live consumer reader" or "live reader" since "consumer" alone can yield some confusion with lttng-consumerd. I would need a reproducer for this, you can base yourself on the reproducer in the commit message for the previous fix. AFAIK there is no valid reason for this to happen, at least based on my review of the code for the fix we just merged. (This is only valid for per-uid tracing, per-pid tracing and lttng live have not so minor limitation inherent to the current lttng-live implementation) > I don't quite understand why that is. Would love some explanations on the > various timing windows where we have a potential to lose the events on the > consumer side. >From a live reader perspective, in per-uid mode, there should be no "loss" of >event from the moment the viewer is attached and the moment it detach. Here >"loss" mean that the events are present in the trace gathered by lttng-relayd >but not by the live reader for the same "time window". This is only valid if >the viewer is not "late" and have consumed everything at the detach moment. Cheers _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
