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

[dgoulet@efficios.com (David Goulet)]

Addendum!

Please replace lttng_stop_session to "lttng_stop_tracing".

Thanks
David

David Goulet:
> 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! :)
> (new) lttng_stop_session_no_wait(session_name) --> naming NOT final.
> 
> (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