[lttng-dev] [RFC] Changes to the stop command

[Mathieu Desnoyers]

* David Goulet (dgoulet at efficios.com) wrote:
> Hi everyone,
> 
> We discovered a week ago a "broken guarantee" which is that when a
> session is stopped by either using the lttng command or the API call
> lttng_stop_session the traced data MUST be ready to be read.
> 
> However, we don't offer that at all for now for both local storage and
> network streaming. The stop command/call simply does _not_ wait for that
> state.
> 
> Here is the proposal to fix this issue before the 2.1 stable release.
> Let's add a new API call (extending it) that probes the session daemon
> for the trace files state (still writing, no more data, closed, ...).
> 
> Ex: lttng_data_state(handle)
> 
> This will bring a change to the default behavior of the stop command.
> From now on, it will wait by default until the data is available to read
> (for both network and local). This will however be done on the client
> side in order to avoid blocking the session daemon client command sub
> system for an unknown amount of time.
> 
> The way I propose we proceed is to use the new API call (mention above)
> on the liblttng-ctl side when a stop is done that requires it to wait.
> Unfortunately, there is no clean way to do that other than an active
> loop polling the session daemon...
> 
> The "no wait" use case of the stop command will also be added with a
> lttng_stop_session_no_wait or something like that.
> 
> In a nutshell:
> 
> (new) lttng_data_state(handle) --> name is NOT final, please chip in for
> ideas! :)

ideas:

- lttng_data_pending()
- lttng_data_available()


> (new) lttng_stop_session_no_wait(session_name) --> naming NOT final.

lttng_stop_session_no_wait sounds ok to me.

The rest looks good. Let's see if others find better names ;)

Thanks,

Mathieu

> 
> (changes) lttng stop (and lttng_stop_session) will now wait for the data
> to be available so babeltrace could be use right after for instance. A
> --no-wait will be added as well to the UI command.
> 
> I would like everyone opinion on that because this is an important issue
> that _MUST_ be fixed in 2.1 stable or at least in the 2.1.x series.
> 
> Thanks a lot!
> David
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com