Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Mathieu Desnoyers]

If you remove this, I think the streams will never get published
within the relayd. (publish_connection_local_streams()). Is this
an expected side-effect ? It should be documented in the changelog.
My guess is that we indeed don't want to publish the snapshot
streams to the viewers.

The reason for doing this change should also be documented. What
behavior is unwanted here from a relayd perspective ?

Thanks,

Mathieu

----- On Aug 23, 2017, at 1:48 PM, Julien Desfossez jdesfossez@efficios.com wrote:

> The relay_streams_sent message is only useful in live sessions and
> should only be sent after all the streams of a channel have been sent.
> 
> Here we were sending this message every time we sent a stream to the
> relay during a snapshot which makes no sense.
> 
> Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
> ---
> src/common/kernel-consumer/kernel-consumer.c | 8 --------
> src/common/ust-consumer/ust-consumer.c       | 6 ------
> 2 files changed, 14 deletions(-)
> 
> diff --git a/src/common/kernel-consumer/kernel-consumer.c
> b/src/common/kernel-consumer/kernel-consumer.c
> index a5dcc66..1c2751b 100644
> --- a/src/common/kernel-consumer/kernel-consumer.c
> +++ b/src/common/kernel-consumer/kernel-consumer.c
> @@ -187,14 +187,6 @@ int lttng_kconsumer_snapshot_channel(uint64_t key, char
> *path,
> 			DBG("Kernel consumer snapshot stream %s/%s (%" PRIu64 ")",
> 					path, stream->name, stream->key);
> 		}
> -		if (relayd_id != -1ULL) {
> -			ret = consumer_send_relayd_streams_sent(relayd_id);
> -			if (ret < 0) {
> -				ERR("sending streams sent to relayd");
> -				goto end_unlock;
> -			}
> -			channel->streams_sent_to_relayd = true;
> -		}
> 
> 		ret = kernctl_buffer_flush_empty(stream->wait_fd);
> 		if (ret < 0) {
> diff --git a/src/common/ust-consumer/ust-consumer.c
> b/src/common/ust-consumer/ust-consumer.c
> index 366f855..bce7db8 100644
> --- a/src/common/ust-consumer/ust-consumer.c
> +++ b/src/common/ust-consumer/ust-consumer.c
> @@ -1101,12 +1101,6 @@ static int snapshot_channel(uint64_t key, char *path,
> uint64_t relayd_id,
> 			DBG("UST consumer snapshot stream %s/%s (%" PRIu64 ")", path,
> 					stream->name, stream->key);
> 		}
> -		if (relayd_id != -1ULL) {
> -			ret = consumer_send_relayd_streams_sent(relayd_id);
> -			if (ret < 0) {
> -				goto error_unlock;
> -			}
> -		}
> 
> 		/*
> 		 * If tracing is active, we want to perform a "full" buffer flush.
> --
> 2.7.4
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Julien Desfossez]

> If you remove this, I think the streams will never get published
> within the relayd. (publish_connection_local_streams()). Is this
> an expected side-effect ? It should be documented in the changelog.
> My guess is that we indeed don't want to publish the snapshot
> streams to the viewers.
Indeed, a snapshot session cannot be a live session, so we don't
want/need to publish those streams. Also, sending this message every
time we send a stream is a wrong usage of the command.

> The reason for doing this change should also be documented. What
> behavior is unwanted here from a relayd perspective ?
We are sending this message to the relay (and waiting for the
confirmation) before taking the snapshot of each stream. So, in addition
to being wrong and useless, it adds a considerable delay before taking
the snapshot of each stream.

Do you agree ?

Thanks,

Julien
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Mathieu Desnoyers]

----- On Aug 24, 2017, at 12:35 PM, Julien Desfossez jdesfossez@efficios.com wrote:

>> If you remove this, I think the streams will never get published
>> within the relayd. (publish_connection_local_streams()). Is this
>> an expected side-effect ? It should be documented in the changelog.
>> My guess is that we indeed don't want to publish the snapshot
>> streams to the viewers.
> Indeed, a snapshot session cannot be a live session, so we don't
> want/need to publish those streams. Also, sending this message every
> time we send a stream is a wrong usage of the command.

You'll need to ensure that we are not freeing the streams too
quickly or leaking them in relayd after your change.

> 
>> The reason for doing this change should also be documented. What
>> behavior is unwanted here from a relayd perspective ?
> We are sending this message to the relay (and waiting for the
> confirmation) before taking the snapshot of each stream. So, in addition
> to being wrong and useless, it adds a considerable delay before taking
> the snapshot of each stream.
> 
> Do you agree ?

It looks like a good idea to remove it. I just want us to make sure the
snapshot mode does not somehow expect the streams to be published
within other parts of the relayd code.

Thanks,

Mathieu

> 
> Thanks,
> 
> Julien

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Julien Desfossez]

>>> If you remove this, I think the streams will never get published
>>> within the relayd. (publish_connection_local_streams()). Is this
>>> an expected side-effect ? It should be documented in the changelog.
>>> My guess is that we indeed don't want to publish the snapshot
>>> streams to the viewers.
>> Indeed, a snapshot session cannot be a live session, so we don't
>> want/need to publish those streams. Also, sending this message every
>> time we send a stream is a wrong usage of the command.
> 
> You'll need to ensure that we are not freeing the streams too
> quickly or leaking them in relayd after your change.

Publishing the stream does not take a new reference on the stream, it
just adds it in the stream_list so it becomes visible in the viewer
thread. So it does not change the lifetime of the stream. And if the
stream is not published when we remove it we don't try to unpublish it.

>>> The reason for doing this change should also be documented. What
>>> behavior is unwanted here from a relayd perspective ?
>> We are sending this message to the relay (and waiting for the
>> confirmation) before taking the snapshot of each stream. So, in addition
>> to being wrong and useless, it adds a considerable delay before taking
>> the snapshot of each stream.
>>
>> Do you agree ?
> 
> It looks like a good idea to remove it. I just want us to make sure the
> snapshot mode does not somehow expect the streams to be published
> within other parts of the relayd code.

It looks good.

Thanks,

Julien
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Mathieu Desnoyers]

----- On Aug 25, 2017, at 12:47 PM, Julien Desfossez jdesfossez@efficios.com wrote:

>>>> If you remove this, I think the streams will never get published
>>>> within the relayd. (publish_connection_local_streams()). Is this
>>>> an expected side-effect ? It should be documented in the changelog.
>>>> My guess is that we indeed don't want to publish the snapshot
>>>> streams to the viewers.
>>> Indeed, a snapshot session cannot be a live session, so we don't
>>> want/need to publish those streams. Also, sending this message every
>>> time we send a stream is a wrong usage of the command.
>> 
>> You'll need to ensure that we are not freeing the streams too
>> quickly or leaking them in relayd after your change.
> 
> Publishing the stream does not take a new reference on the stream, it
> just adds it in the stream_list so it becomes visible in the viewer
> thread. So it does not change the lifetime of the stream. And if the
> stream is not published when we remove it we don't try to unpublish it.
> 
>>>> The reason for doing this change should also be documented. What
>>>> behavior is unwanted here from a relayd perspective ?
>>> We are sending this message to the relay (and waiting for the
>>> confirmation) before taking the snapshot of each stream. So, in addition
>>> to being wrong and useless, it adds a considerable delay before taking
>>> the snapshot of each stream.
>>>
>>> Do you agree ?
>> 
>> It looks like a good idea to remove it. I just want us to make sure the
>> snapshot mode does not somehow expect the streams to be published
>> within other parts of the relayd code.
> 
> It looks good.

Allright then, thanks!

Mathieu

> 
> Thanks,
> 
> Julien

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Jérémie Galarneau]

Merged, thanks!

Jérémie

On 23 August 2017 at 16:48, Julien Desfossez <jdesfossez@efficios.com> wrote:
> The relay_streams_sent message is only useful in live sessions and
> should only be sent after all the streams of a channel have been sent.
>
> Here we were sending this message every time we sent a stream to the
> relay during a snapshot which makes no sense.
>
> Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
> ---
>  src/common/kernel-consumer/kernel-consumer.c | 8 --------
>  src/common/ust-consumer/ust-consumer.c       | 6 ------
>  2 files changed, 14 deletions(-)
>
> diff --git a/src/common/kernel-consumer/kernel-consumer.c b/src/common/kernel-consumer/kernel-consumer.c
> index a5dcc66..1c2751b 100644
> --- a/src/common/kernel-consumer/kernel-consumer.c
> +++ b/src/common/kernel-consumer/kernel-consumer.c
> @@ -187,14 +187,6 @@ int lttng_kconsumer_snapshot_channel(uint64_t key, char *path,
>                         DBG("Kernel consumer snapshot stream %s/%s (%" PRIu64 ")",
>                                         path, stream->name, stream->key);
>                 }
> -               if (relayd_id != -1ULL) {
> -                       ret = consumer_send_relayd_streams_sent(relayd_id);
> -                       if (ret < 0) {
> -                               ERR("sending streams sent to relayd");
> -                               goto end_unlock;
> -                       }
> -                       channel->streams_sent_to_relayd = true;
> -               }
>
>                 ret = kernctl_buffer_flush_empty(stream->wait_fd);
>                 if (ret < 0) {
> diff --git a/src/common/ust-consumer/ust-consumer.c b/src/common/ust-consumer/ust-consumer.c
> index 366f855..bce7db8 100644
> --- a/src/common/ust-consumer/ust-consumer.c
> +++ b/src/common/ust-consumer/ust-consumer.c
> @@ -1101,12 +1101,6 @@ static int snapshot_channel(uint64_t key, char *path, uint64_t relayd_id,
>                         DBG("UST consumer snapshot stream %s/%s (%" PRIu64 ")", path,
>                                         stream->name, stream->key);
>                 }
> -               if (relayd_id != -1ULL) {
> -                       ret = consumer_send_relayd_streams_sent(relayd_id);
> -                       if (ret < 0) {
> -                               goto error_unlock;
> -                       }
> -               }
>
>                 /*
>                  * If tracing is active, we want to perform a "full" buffer flush.
> --
> 2.7.4
>



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[PATCH lttng-tools v2] Fix: wrong use of the relay_streams_sent in snapshot

[Julien Desfossez]

The relay_streams_sent message is only useful in live sessions and
should only be sent after all the streams of a channel have been sent.

Here we were sending this message every time we sent a stream to the
relay during a snapshot which makes no sense.

Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
---
 src/common/kernel-consumer/kernel-consumer.c | 8 --------
 src/common/ust-consumer/ust-consumer.c       | 6 ------
 2 files changed, 14 deletions(-)

diff --git a/src/common/kernel-consumer/kernel-consumer.c b/src/common/kernel-consumer/kernel-consumer.c
index a5dcc66..1c2751b 100644
--- a/src/common/kernel-consumer/kernel-consumer.c
+++ b/src/common/kernel-consumer/kernel-consumer.c
@@ -187,14 +187,6 @@ int lttng_kconsumer_snapshot_channel(uint64_t key, char *path,
 			DBG("Kernel consumer snapshot stream %s/%s (%" PRIu64 ")",
 					path, stream->name, stream->key);
 		}
-		if (relayd_id != -1ULL) {
-			ret = consumer_send_relayd_streams_sent(relayd_id);
-			if (ret < 0) {
-				ERR("sending streams sent to relayd");
-				goto end_unlock;
-			}
-			channel->streams_sent_to_relayd = true;
-		}
 
 		ret = kernctl_buffer_flush_empty(stream->wait_fd);
 		if (ret < 0) {
diff --git a/src/common/ust-consumer/ust-consumer.c b/src/common/ust-consumer/ust-consumer.c
index 366f855..bce7db8 100644
--- a/src/common/ust-consumer/ust-consumer.c
+++ b/src/common/ust-consumer/ust-consumer.c
@@ -1101,12 +1101,6 @@ static int snapshot_channel(uint64_t key, char *path, uint64_t relayd_id,
 			DBG("UST consumer snapshot stream %s/%s (%" PRIu64 ")", path,
 					stream->name, stream->key);
 		}
-		if (relayd_id != -1ULL) {
-			ret = consumer_send_relayd_streams_sent(relayd_id);
-			if (ret < 0) {
-				goto error_unlock;
-			}
-		}
 
 		/*
 		 * If tracing is active, we want to perform a "full" buffer flush.
-- 
2.7.4

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev