From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id x/FhKL5dkWAhZAAAWB0awg (envelope-from ) for ; Tue, 04 May 2021 10:44:14 -0400 Received: by simark.ca (Postfix, from userid 112) id 94D271F11C; Tue, 4 May 2021 10:44:14 -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 A960F1E54D for ; Tue, 4 May 2021 10:44:13 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4FZMzx06Rgz1h6Z; Tue, 4 May 2021 10:44:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1620139453; bh=TSKIPxAP1OtYnDRiwQz9gMLYQskFy/r/dPi2Ylm4goo=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=v5JvLGQfK/7KoSnNzG9Etelf520foopekpl1kSDxDULSDClNEcnQuSStQ8r5HD26h hFqzzS5m2FppmKgyK8sNu77rwPxCR5wD1s2V1Kv3jOvpzYIXNUT3vbyzNkrR2jU4QA 0/pln6RCW9As2JaCnMh51TitnMeiCQzbOFTX8Ar5hTEkNTMUgyrIz86d6sIwHKp3gu LkRkt6eYyE6mEjiP/Jcns9+SZEMDQ39aBP5o5sxs4W918ljFqt9s/AqnQLmTzv9eSw 3pls5hAK4ptCS3xHCFMnERAWqEigOwbf/s0sSfoRahJbd/f7+g0ZUltrLP2cndeitL quEzncMaSLAEA== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4FZMzv75jDz1h1p for ; Tue, 4 May 2021 10:44:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 857532E33F4 for ; Tue, 4 May 2021 10:44:05 -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 eQkcp-qDAm94; Tue, 4 May 2021 10:44:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 0D2332E2E86; Tue, 4 May 2021 10:44:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 0D2332E2E86 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 ZHcS1bce_DML; Tue, 4 May 2021 10:44:05 -0400 (EDT) Received: from joraj-alpa (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) by mail.efficios.com (Postfix) with ESMTPSA id B8B1C2E32EF; Tue, 4 May 2021 10:44:04 -0400 (EDT) Date: Tue, 4 May 2021 10:44:03 -0400 To: Eqbal Cc: lttng-dev@lists.lttng.org Message-ID: <20210504144403.GB346954@joraj-alpa> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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" On Mon, May 03, 2021 at 05:05:10PM -0700, Eqbal via lttng-dev wrote: > Hi, > > I have a lttng live session trace consumer application using libbabeltrace2 > where I create a graph to consume lttng live session traces and output to > another sink. I am running the graph in a loop at some polling interval as > long as I get BT_GRAPH_RUN_STATUS_AGAIN status. What I am noticing is that > if my polling interval is large enough I tend to lose either all or some of > the events. I experimented with various polling intervals and it seems if > the polling interval is less than *DELAYUS *from "lttng-create > --live=DELAYUS" option then I am able to get all the events, otherwise I > tend to lose events. > > Here are the steps I follow: > 1. start session daemon and relay daemon > 2. create a live session (with default delay of 1s), enable events and start > 3. Start my application (hello world example from lttng docs) Not sure if you modified it in any way, but be careful with short lived apps since an app can terminate before lttng-ust have a chance to register. > 4. Start the consumer application built using libbabeltrace that connects > to the live session hmm. Note that when attaching to a session it does not start at the beginning of the trace collected by lttng-relayd, it start at the last received data from lttng-relayd from the lttng-consumerd (LTTNG_VIEWER_SEEK_LAST). Hence I would recommend that these steps be inversed: 4. Start the consumer application built using libbabeltrace that connects to the live session 3. Start my application (hello world example from lttng docs) > > I noticed that the events are actually persisted in the ~/lttng-traces by > the relay daemon, but it does not reach babeltrace consumer application. I > have noticed the same behavior with babeltrace2 cli. > > I would like to understand what is the reason for such behavior and if > playing with the polling interval in relation to the DELAYUS value is the > right thing to do. I think I reproduced the issue but I'm not completely sure it is the same problem. Please file an issue on the bug tracker [1] with as much information as possible, the exact lttng commands used, the current behaviour and the expected behaviour. I'll add my findings if relevant. But I think it might be a weird handling of how we handle the first "empty" retry and the subsequent get phase. After the initial phase everything seems to work as expected. [1] https://bugs.lttng.org/ -- Jonathan Rajotte-Julien EfficiOS _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev