Community
Participate
Working Groups
When fixing the events view, I noticed that LTTng experiments don't report the right number of events. The total number of events is calculated when indexing the traces (i.e. creating the experiment checkpoints). It turns out that background requests (e.g. indexing the experiment) are broken into sub-requests to provide "slots" so that foreground requests (UI related) can be executed more dynamically. To "optimize" things, the sub-request are set to coincide with the experiment checkpoints so the experiment can be positioned rapidly for each sub-request. The problem comes from the way the LTTng trace location is handled (location + various flags). When building the checkpoints, the location that is stored is actually the location of the *previous* event along with the flags meaning that event was read and that the actual event is the next one (yes, LTTng sucks...). When restoring the checkpoint, the flags are not correctly handled and we end up re-reading the previous event. This is not such a big deal since this particular problem only occurs when indexing the (LTTng) experiment. The quick timestamp fix is quite simple - adjust the TS before storing the checkpoint - but it breaks the other, "well-behaved" applications :-(
Created attachment 178539 [details] Temporary fix Temporary fix: create LTTngExperiment class (which extends the TmfExperiment base class) and provide the quick and dirty fix.
Comment on attachment 178539 [details] Temporary fix Patch committed to Indigo
Patch committed to Helios
Good enough for Helios. For Indigo, we will re-assess after revisiting the TmfContext API.
Delivered with 0.7
