[lttng-dev] Snapshot gives no events after calling it more then the number sub-buffers in the channel

[Anders Wallin]

On Thu, Dec 8, 2016 at 6:35 PM, Mathieu Desnoyers <
mathieu.desnoyers at efficios.com> wrote:

> ----- On Dec 7, 2016, at 9:27 AM, Anders Wallin <wallinux at gmail.com>
> wrote:
>
> Hi,
> Taking a number of snapshots always showed the events in the buffer,
> before the
> commit de3fb857f034c208c135a10a3cdec2dfe43fbda6
>
>     Fix: ust-consumer: flush empty packets on snapshot channel
>     Snapshot operation on a non-stopped stream should use a "final" flush
> to
>     ensure empty packets are flushed, so we gather timestamps at the moment
>     where the snapshot is taken. This is important for streams that have a
>     low amount of activity, which might be on an empty packet when the
>     snapshot is triggered.
>
> After this the number of snapshots that can be taken and getting events is
> equal to number of sub-buffers!?
> I think this i BUG!
>
>
> Hi,
>
> This has been done on purpose. By moving one packet forward even if there
> is no data
> in the current packet, we are able to save the end timestamp corresponding
> to the moment the
> snapshot is taken, which gives us information about the proper time-range
> to consider for each
> stream.
>
> This is needed for the babeltrace stream intersection feature to work
> properly on
> snapshots in cases where some streams have low even throughput.
>
> Can you describe your use-cases that rely on the prior behavior ?
>
> Thanks,
>
> Mathieu
>

The use-case is that we rely on that all events are still in the buffer.
Taken the snapshot is done by different applications/people.
We know the the snapshots will be overwritten when the buffer is full.
This patch introduced a new behavior in a stable release serie which is
strange.  For me this would be something that could change if you make a
new feature
release, even if it should break use and test cases when we moved to this
version.
I understand that the patch fixes another issue, but is there any other way
to solve this issue and keep the existing behavior?

Anders Wallin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20161209/da8b2290/attachment.html>