lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Rajotte-Julien via lttng-dev <lttng-dev@lists.lttng.org>
To: Eqbal <eqbalzee@gmail.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] lttng live event loss with babeltrace2
Date: Mon, 10 May 2021 21:14:54 -0400 (EDT)	[thread overview]
Message-ID: <1156967432.37397.1620695694212.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CAPj=Wkgmf1xGq0H4ka5B5KyXipGReFMuQo4=aMK5NS6fPVL3oA@mail.gmail.com>

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" <eqbalzee@gmail.com>
> To: "Jonathan Rajotte-Julien" <jonathan.rajotte-julien@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

      reply	other threads:[~2021-05-11  1:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-04  0:05 Eqbal via lttng-dev
2021-05-04 13:16 ` Jonathan Rajotte-Julien via lttng-dev
2021-05-04 14:44 ` Jonathan Rajotte-Julien via lttng-dev
2021-05-07 18:05 ` Jonathan Rajotte-Julien via lttng-dev
2021-05-11  0:35   ` Eqbal via lttng-dev
2021-05-11  1:14     ` Jonathan Rajotte-Julien via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1156967432.37397.1620695694212.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=eqbalzee@gmail.com \
    --cc=jonathan.rajotte-julien@efficios.com \
    --subject='Re: [lttng-dev] lttng live event loss with babeltrace2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).