From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TP9/KpjamWBFLwAAWB0awg (envelope-from ) for ; Mon, 10 May 2021 21:15:04 -0400 Received: by simark.ca (Postfix, from userid 112) id 9E03C1F11C; Mon, 10 May 2021 21:15:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B56611E783 for ; Mon, 10 May 2021 21:15:03 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4FfKj26bXwz1lrC; Mon, 10 May 2021 21:15:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1620695703; bh=Qq9Jv3cevd2rFdI2W7kUdvdMF37N5I/sYEzJFnc2iWg=; h=Date:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=PF8hWlLOE8wrsQGt0JSW3fSf+lXwgmugsoA/vXBadDxZBadGG7KutpFCkoz1f9S/M TJ1HriqKHXaG2/7cV9Otufn23/aFSKhpsiEU+KNgf8jqObB9OBEio6opwCIhSyxrIO ge6+Y8OPCEfVGAFuoYnH7Oeo5v3di9ZZ7pCEAsHz3baOChxcYsoiSUBeJCfRWrLt3b UGfX1KF1CN9EpfvKHZb8Hh5sNSojyRLgM/vIEivTHOkrHRiY/edv5w7yYxm5VrunY1 r4Li6ZnLLkmJZQMjbCFPuoWFU9256EDsbA/joyxedU5+njifq2dbV26HZyGYYpFNwo UN3xZBvG3clWg== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4FfKj11QPGz1lr7 for ; Mon, 10 May 2021 21:15:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id CE8ED347B3B for ; Mon, 10 May 2021 21:14:54 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EI55p3w6OO7N; Mon, 10 May 2021 21:14:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 5B6C1347C2E; Mon, 10 May 2021 21:14:54 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 5B6C1347C2E X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id htUIzRyV29Zy; Mon, 10 May 2021 21:14:54 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 4BDBD3479E4; Mon, 10 May 2021 21:14:54 -0400 (EDT) Date: Mon, 10 May 2021 21:14:54 -0400 (EDT) To: Eqbal Cc: lttng-dev Message-ID: <1156967432.37397.1620695694212.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20210507180532.GA1227214@joraj-alpa> MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - GC90 (Linux)/8.8.15_GA_4007) Thread-Topic: lttng live event loss with babeltrace2 Thread-Index: WCkwGOXYVXpSVj8E2HspOf3nc4OjIA== Subject: Re: [lttng-dev] lttng live event loss with babeltrace2 X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Jonathan Rajotte-Julien via lttng-dev Reply-To: Jonathan Rajotte-Julien Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" 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" > To: "Jonathan Rajotte-Julien" > Cc: "lttng-dev" > 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