4 The purpose of the '''Tracing Monitoring Framework (TMF)''' is to facilitate the integration of tracing and monitoring tools into Eclipse, to provide out-of-the-box generic functionalities/views and provide extension mechanisms of the base functionalities for application specific purposes.
6 = Implementing a New Trace Type =
8 The framework can easily be extended to support more trace types. To make a new trace type, one must define the following items:
14 * The ''org.eclipse.linuxtools.tmf.core.tracetype'' plug-in extension point
15 * (Optional) The ''org.eclipse.linuxtools.tmf.ui.tracetypeui'' plug-in extension point
17 The '''event type''' must implement an ''ITmfEvent'' or extend a class that implements an ''ITmfEvent''. Typically it will extend ''TmfEvent''. The event type must contain all the data of an event. The '''trace reader''' must be of an ''ITmfTrace'' type. The ''TmfTrace'' class will supply many background operations so that the reader only needs to implement certain functions. The '''trace context''' can be seen as the internals of an iterator. It is required by the trace reader to parse events as it iterates the trace and to keep track of its rank and location. It can have a timestamp, a rank, a file position, or any other element, it should be considered to be ephemeral. The '''trace location''' is an element that is cloned often to store checkpoints, it is generally persistent. It is used to rebuild a context, therefore, it needs to contain enough information to unambiguously point to one and only one event. Finally the ''tracetype'' plug-in extension associates a given trace, non-programmatically to a trace type for use in the UI.
19 == An Example: Nexus-lite parser ==
21 === Description of the file ===
23 This is a very small subset of the nexus trace format, with some changes to make it easier to read. There is one file. This file starts with 64 Strings containing the event names, then an arbitrarily large number of events. The events are each 64 bits long. the first 32 are the timestamp in microseconds, the second 32 are split into 6 bits for the event type, and 26 for the data payload.
25 The trace type will be made of two parts, part 1 is the event description, it is just 64 strings, comma seperated and then a line feed.
28 Startup,Stop,Load,Add, ... ,reserved\n
31 Then there will be the events in this format
34 |style="width: 50%; background-color: #ffffcc;"|timestamp (32 bits)
35 |style="width: 10%; background-color: #ffccff;"|type (6 bits)
36 |style="width: 40%; background-color: #ccffcc;"|payload (26 bits)
38 |style="background-color: #ffcccc;" colspan="3"|64 bits total
41 all events will be the same size (64 bits).
43 === NexusLite Plug-in ===
45 Create a '''New''', '''Project...''', '''Plug-in Project''', set the title to '''com.example.nexuslite''', click '''Next >''' then click on '''Finish'''.
47 Now the structure for the Nexus trace Plug-in is set up.
49 Add a dependency to TMF core and UI by opening the '''MANIFEST.MF''' in '''META-INF''', selecting the '''Dependencies''' tab and '''Add ...''' '''org.eclipse.linuxtools.tmf.core''' and '''org.eclipse.linuxtools.tmf.ui'''.
51 [[Image:images/NTTAddDepend.png]]<br>
52 [[Image:images/NTTSelectProjects.png]]<br>
54 Now the project can access TMF classes.
58 The '''TmfEvent''' class will work for this example. No code required.
62 The trace reader will extend a '''TmfTrace''' class.
64 It will need to implement:
66 * validate (is the trace format valid?)
68 * initTrace (called as the trace is opened
70 * seekEvent (go to a position in the trace and create a context)
72 * getNext (implemented in the base class)
74 * parseEvent (read the next element in the trace)
76 For reference, there is an example implementation of the Nexus Trace file in
77 org.eclipse.linuxtools.tracing.examples.core.trace.nexus.NexusTrace.java.
79 In this example, the '''validate''' function checks first checks if the file
80 exists, then makes sure that it is really a file, and not a directory. Then we
81 attempt to read the file header, to make sure that it is really a Nexus Trace.
82 If that check passes, we return a TmfValidationStatus with a confidence of 20.
84 Typically, TmfValidationStatus confidences should range from 1 to 100. 1 meaning
85 "there is a very small chance that this trace is of this type", and 100 meaning
86 "it is this type for sure, and cannot be anything else". At run-time, the
87 auto-detection will pick the the type which returned the highest confidence. So
88 checks of the type "does the file exist?" should not return a too high
91 Here we used a confidence of 20, to leave "room" for more specific trace types
92 in the Nexus format that could be defined in TMF.
94 The '''initTrace''' function will read the event names, and find where the data starts. After this, the number of events is known, and since each event is 8 bytes long according to the specs, the seek is then trivial.
96 The '''seek''' here will just reset the reader to the right location.
98 The '''parseEvent''' method needs to parse and return the current event and store the current location.
100 The '''getNext''' method (in base class) will read the next event and update the context. It calls the '''parseEvent''' method to read the event and update the location. It does not need to be overridden and in this example it is not. The sequence of actions necessary are parse the next event from the trace, create an '''ITmfEvent''' with that data, update the current location, call '''updateAttributes''', update the context then return the event.
102 Traces will typically implement an index, to make seeking faster. The index can
103 be rebuilt every time the trace is opened. Alternatively, it can be saved to
104 disk, to make future openings of the same trace quicker. To do so, the trace
105 object can implement the '''ITmfPersistentlyIndexable''' interface.
107 === Trace Context ===
109 The trace context will be a '''TmfContext'''
111 === Trace Location ===
113 The trace location will be a long, representing the rank in the file. The '''TmfLongLocation''' will be the used, once again, no code is required.
115 === The ''org.eclipse.linuxtools.tmf.core.tracetype'' and ''org.eclipse.linuxtools.tmf.ui.tracetypeui'' plug-in extension point ===
117 One should implement the ''tmf.core.tracetype'' extension in their own plug-in.
118 In this example, the Nexus trace plug-in will be modified.
120 The '''plugin.xml''' file in the ui plug-in needs to be updated if one wants users to access the given event type. It can be updated in the Eclipse plug-in editor.
122 # In Extensions tab, add the '''org.eclipse.linuxtools.tmf.core.tracetype''' extension point.
123 [[Image:images/NTTExtension.png]]<br>
124 [[Image:images/NTTTraceType.png]]<br>
125 [[Image:images/NTTExtensionPoint.png]]<br>
127 # Add in the '''org.eclipse.linuxtools.tmf.ui.tracetype''' extension a new type. To do that, '''right click''' on the extension then in the context menu, go to '''New >''', '''type'''.
129 [[Image:images/NTTAddType.png]]<br>
131 The '''id''' is the unique identifier used to refer to the trace.
133 The '''name''' is the field that shall be displayed when a trace type is selected.
135 The '''trace type''' is the canonical path refering to the class of the trace.
137 The '''event type''' is the canonical path refering to the class of the events of a given trace.
139 The '''category''' (optional) is the container in which this trace type will be stored.
141 # (Optional) To also add UI-specific properties to your trace type, use the '''org.eclipse.linuxtools.tmf.ui.tracetypeui''' extension. To do that,
142 '''right click''' on the extension then in the context menu, go to
143 '''New >''', '''type'''.
145 The '''tracetype''' here is the '''id''' of the
146 ''org.eclipse.linuxtools.tmf.core.tracetype'' mentioned above.
148 The '''icon''' is the image to associate with that trace type.
150 In the end, the extension menu should look like this.
152 [[Image:images/NTTPluginxmlComplete.png]]<br>
154 == Other Considerations ==
155 The ''org.eclipse.linuxtools.tmf.ui.viewers.events.TmfEventsTable'' provides additional features that are active when the event class (defined in '''event type''') implements certain additional interfaces.
157 === Collapsing of repetitive events ===
158 By implementing the interface ''org.eclipse.linuxtools.tmf.core.event.collapse.ITmfCollapsibleEvent'' the events table will allow to collapse repetitive events by selecting the menu item '''Collapse Events''' after pressing the right mouse button in the table.
162 * Do not load the whole trace in RAM, it will limit the size of the trace that can be read.
163 * Reuse as much code as possible, it makes the trace format much easier to maintain.
164 * Use Eclipse's editor instead of editing the XML directly.
165 * Do not forget Java supports only signed data types, there may be special care needed to handle unsigned data.
166 * If the support for your trace has custom UI elements (like icons, views, etc.), split the core and UI parts in separate plugins, named identically except for a ''.core'' or ''.ui'' suffix.
167 ** Implement the ''tmf.core.tracetype'' extension in the core plugin, and the ''tmf.ui.tracetypeui'' extension in the UI plugin if applicable.
169 == Download the Code ==
171 The described example is available in the
172 org.eclipse.linuxtools.tracing.examples.(tests.)trace.nexus packages with a
173 trace generator and a quick test case.
175 == Optional Trace Type Attributes ==
177 After defining the trace type as described in the previous chapters it is possible to define optional attributes for the trace type.
179 === Default Editor ===
181 The '''defaultEditor''' attribute of the '''org.eclipse.tmf.ui.tracetypeui'''
182 extension point allows for configuring the editor to use for displaying the
183 events. If omitted, the ''TmfEventsEditor'' is used as default.
185 To configure an editor, first add the '''defaultEditor''' attribute to the trace
186 type in the extension definition. This can be done by selecting the trace type
187 in the plug-in manifest editor. Then click the right mouse button and select
188 '''New -> defaultEditor''' in the context sensitive menu. Then select the newly
189 added attribute. Now you can specify the editor id to use on the right side of
190 the manifest editor. For example, this attribute could be used to implement an
191 extension of the class ''org.eclipse.ui.part.MultiPageEditor''. The first page
192 could use the ''TmfEventsEditor''' to display the events in a table as usual and
193 other pages can display other aspects of the trace.
195 === Events Table Type ===
197 The '''eventsTableType''' attribute of the '''org.eclipse.tmf.ui.tracetypeui'''
198 extension point allows for configuring the events table class to use in the
199 default events editor. If omitted, the default events table will be used.
201 To configure a trace type specific events table, first add the
202 '''eventsTableType''' attribute to the trace type in the extension definition.
203 This can be done by selecting the trace type in the plug-in manifest editor.
204 Then click the right mouse button and select '''New -> eventsTableType''' in the
205 context sensitive menu. Then select the newly added attribute and click on
206 ''class'' on the right side of the manifest editor. The new class wizard will
207 open. The ''superclass'' field will be already filled with the class ''org.eclipse.linuxtools.tmf.ui.viewers.events.TmfEventsTable''.
209 By using this attribute, a table with different columns than the default columns
210 can be defined. See the class org.eclipse.linuxtools.internal.lttng2.kernel.ui.viewers.events.Lttng2EventsTable
211 for an example implementation.
215 This tutorial describes how to create a simple view using the TMF framework and the SWTChart library. SWTChart is a library based on SWT that can draw several types of charts including a line chart which we will use in this tutorial. We will create a view containing a line chart that displays time stamps on the X axis and the corresponding event values on the Y axis.
217 This tutorial will cover concepts like:
220 * Signal handling (@TmfSignalHandler)
221 * Data requests (TmfEventRequest)
222 * SWTChart integration
224 '''Note''': TMF 3.0.0 provides base implementations for generating SWTChart viewers and views. For more details please refer to chapter [[#TMF Built-in Views and Viewers]].
226 === Prerequisites ===
228 The tutorial is based on Eclipse 4.4 (Eclipse Luna), TMF 3.0.0 and SWTChart 0.7.0. If you are using TMF from the source repository, SWTChart is already included in the target definition file (see org.eclipse.linuxtools.lttng.target). You can also install it manually by using the Orbit update site. http://download.eclipse.org/tools/orbit/downloads/
230 === Creating an Eclipse UI Plug-in ===
232 To create a new project with name org.eclipse.linuxtools.tmf.sample.ui select '''File -> New -> Project -> Plug-in Development -> Plug-in Project'''. <br>
233 [[Image:images/Screenshot-NewPlug-inProject1.png]]<br>
235 [[Image:images/Screenshot-NewPlug-inProject2.png]]<br>
237 [[Image:images/Screenshot-NewPlug-inProject3.png]]<br>
239 === Creating a View ===
241 To open the plug-in manifest, double-click on the MANIFEST.MF file. <br>
242 [[Image:images/SelectManifest.png]]<br>
244 Change to the Dependencies tab and select '''Add...''' of the ''Required Plug-ins'' section. A new dialog box will open. Next find plug-in ''org.eclipse.linuxtools.tmf.core'' and press '''OK'''<br>
245 Following the same steps, add ''org.eclipse.linuxtools.tmf.ui'' and ''org.swtchart''.<br>
246 [[Image:images/AddDependencyTmfUi.png]]<br>
248 Change to the Extensions tab and select '''Add...''' of the ''All Extension'' section. A new dialog box will open. Find the view extension ''org.eclipse.ui.views'' and press '''Finish'''.<br>
249 [[Image:images/AddViewExtension1.png]]<br>
251 To create a view, click the right mouse button. Then select '''New -> view'''<br>
252 [[Image:images/AddViewExtension2.png]]<br>
254 A new view entry has been created. Fill in the fields ''id'' and ''name''. For ''class'' click on the '''class hyperlink''' and it will show the New Java Class dialog. Enter the name ''SampleView'', change the superclass to ''TmfView'' and click Finish. This will create the source file and fill the ''class'' field in the process. We use TmfView as the superclass because it provides extra functionality like getting the active trace, pinning and it has support for signal handling between components.<br>
255 [[Image:images/FillSampleViewExtension.png]]<br>
257 This will generate an empty class. Once the quick fixes are applied, the following code is obtained:
260 package org.eclipse.linuxtools.tmf.sample.ui;
262 import org.eclipse.swt.widgets.Composite;
263 import org.eclipse.ui.part.ViewPart;
265 public class SampleView extends TmfView {
267 public SampleView(String viewName) {
269 // TODO Auto-generated constructor stub
273 public void createPartControl(Composite parent) {
274 // TODO Auto-generated method stub
279 public void setFocus() {
280 // TODO Auto-generated method stub
287 This creates an empty view, however the basic structure is now is place.
289 === Implementing a view ===
291 We will start by adding a empty chart then it will need to be populated with the trace data. Finally, we will make the chart more visually pleasing by adjusting the range and formating the time stamps.
293 ==== Adding an Empty Chart ====
295 First, we can add an empty chart to the view and initialize some of its components.
298 private static final String SERIES_NAME = "Series";
299 private static final String Y_AXIS_TITLE = "Signal";
300 private static final String X_AXIS_TITLE = "Time";
301 private static final String FIELD = "value"; // The name of the field that we want to display on the Y axis
302 private static final String VIEW_ID = "org.eclipse.linuxtools.tmf.sample.ui.view";
304 private ITmfTrace currentTrace;
306 public SampleView() {
311 public void createPartControl(Composite parent) {
312 chart = new Chart(parent, SWT.BORDER);
313 chart.getTitle().setVisible(false);
314 chart.getAxisSet().getXAxis(0).getTitle().setText(X_AXIS_TITLE);
315 chart.getAxisSet().getYAxis(0).getTitle().setText(Y_AXIS_TITLE);
316 chart.getSeriesSet().createSeries(SeriesType.LINE, SERIES_NAME);
317 chart.getLegend().setVisible(false);
321 public void setFocus() {
326 The view is prepared. Run the Example. To launch the an Eclipse Application select the ''Overview'' tab and click on '''Launch an Eclipse Application'''<br>
327 [[Image:images/RunEclipseApplication.png]]<br>
329 A new Eclipse application window will show. In the new window go to '''Windows -> Show View -> Other... -> Other -> Sample View'''.<br>
330 [[Image:images/ShowViewOther.png]]<br>
332 You should now see a view containing an empty chart<br>
333 [[Image:images/EmptySampleView.png]]<br>
335 ==== Signal Handling ====
337 We would like to populate the view when a trace is selected. To achieve this, we can use a signal hander which is specified with the '''@TmfSignalHandler''' annotation.
341 public void traceSelected(final TmfTraceSelectedSignal signal) {
346 ==== Requesting Data ====
348 Then we need to actually gather data from the trace. This is done asynchronously using a ''TmfEventRequest''
352 public void traceSelected(final TmfTraceSelectedSignal signal) {
353 // Don't populate the view again if we're already showing this trace
354 if (currentTrace == signal.getTrace()) {
357 currentTrace = signal.getTrace();
359 // Create the request to get data from the trace
361 TmfEventRequest req = new TmfEventRequest(TmfEvent.class,
362 TmfTimeRange.ETERNITY, 0, ITmfEventRequest.ALL_DATA,
363 ITmfEventRequest.ExecutionType.BACKGROUND) {
366 public void handleData(ITmfEvent data) {
367 // Called for each event
368 super.handleData(data);
372 public void handleSuccess() {
373 // Request successful, not more data available
374 super.handleSuccess();
378 public void handleFailure() {
379 // Request failed, not more data available
380 super.handleFailure();
383 ITmfTrace trace = signal.getTrace();
384 trace.sendRequest(req);
388 ==== Transferring Data to the Chart ====
390 The chart expects an array of doubles for both the X and Y axis values. To provide that, we can accumulate each event's time and value in their respective list then convert the list to arrays when all events are processed.
393 TmfEventRequest req = new TmfEventRequest(TmfEvent.class,
394 TmfTimeRange.ETERNITY, 0, ITmfEventRequest.ALL_DATA,
395 ITmfEventRequest.ExecutionType.BACKGROUND) {
397 ArrayList<Double> xValues = new ArrayList<Double>();
398 ArrayList<Double> yValues = new ArrayList<Double>();
401 public void handleData(ITmfEvent data) {
402 // Called for each event
403 super.handleData(data);
404 ITmfEventField field = data.getContent().getField(FIELD);
406 yValues.add((Double) field.getValue());
407 xValues.add((double) data.getTimestamp().getValue());
412 public void handleSuccess() {
413 // Request successful, not more data available
414 super.handleSuccess();
416 final double x[] = toArray(xValues);
417 final double y[] = toArray(yValues);
419 // This part needs to run on the UI thread since it updates the chart SWT control
420 Display.getDefault().asyncExec(new Runnable() {
424 chart.getSeriesSet().getSeries()[0].setXSeries(x);
425 chart.getSeriesSet().getSeries()[0].setYSeries(y);
434 * Convert List<Double> to double[]
436 private double[] toArray(List<Double> list) {
437 double[] d = new double[list.size()];
438 for (int i = 0; i < list.size(); ++i) {
447 ==== Adjusting the Range ====
449 The chart now contains values but they might be out of range and not visible. We can adjust the range of each axis by computing the minimum and maximum values as we add events.
453 ArrayList<Double> xValues = new ArrayList<Double>();
454 ArrayList<Double> yValues = new ArrayList<Double>();
455 private double maxY = -Double.MAX_VALUE;
456 private double minY = Double.MAX_VALUE;
457 private double maxX = -Double.MAX_VALUE;
458 private double minX = Double.MAX_VALUE;
461 public void handleData(ITmfEvent data) {
462 super.handleData(data);
463 ITmfEventField field = data.getContent().getField(FIELD);
465 Double yValue = (Double) field.getValue();
466 minY = Math.min(minY, yValue);
467 maxY = Math.max(maxY, yValue);
470 double xValue = (double) data.getTimestamp().getValue();
472 minX = Math.min(minX, xValue);
473 maxX = Math.max(maxX, xValue);
478 public void handleSuccess() {
479 super.handleSuccess();
480 final double x[] = toArray(xValues);
481 final double y[] = toArray(yValues);
483 // This part needs to run on the UI thread since it updates the chart SWT control
484 Display.getDefault().asyncExec(new Runnable() {
488 chart.getSeriesSet().getSeries()[0].setXSeries(x);
489 chart.getSeriesSet().getSeries()[0].setYSeries(y);
492 if (!xValues.isEmpty() && !yValues.isEmpty()) {
493 chart.getAxisSet().getXAxis(0).setRange(new Range(0, x[x.length - 1]));
494 chart.getAxisSet().getYAxis(0).setRange(new Range(minY, maxY));
496 chart.getAxisSet().getXAxis(0).setRange(new Range(0, 1));
497 chart.getAxisSet().getYAxis(0).setRange(new Range(0, 1));
499 chart.getAxisSet().adjustRange();
507 ==== Formatting the Time Stamps ====
509 To display the time stamps on the X axis nicely, we need to specify a format or else the time stamps will be displayed as ''long''. We use TmfTimestampFormat to make it consistent with the other TMF views. We also need to handle the '''TmfTimestampFormatUpdateSignal''' to make sure that the time stamps update when the preferences change.
513 public void createPartControl(Composite parent) {
516 chart.getAxisSet().getXAxis(0).getTick().setFormat(new TmfChartTimeStampFormat());
519 public class TmfChartTimeStampFormat extends SimpleDateFormat {
520 private static final long serialVersionUID = 1L;
522 public StringBuffer format(Date date, StringBuffer toAppendTo, FieldPosition fieldPosition) {
523 long time = date.getTime();
524 toAppendTo.append(TmfTimestampFormat.getDefaulTimeFormat().format(time));
530 public void timestampFormatUpdated(TmfTimestampFormatUpdateSignal signal) {
531 // Called when the time stamp preference is changed
532 chart.getAxisSet().getXAxis(0).getTick().setFormat(new TmfChartTimeStampFormat());
537 We also need to populate the view when a trace is already selected and the view is opened. We can reuse the same code by having the view send the '''TmfTraceSelectedSignal''' to itself.
541 public void createPartControl(Composite parent) {
544 ITmfTrace trace = getActiveTrace();
546 traceSelected(new TmfTraceSelectedSignal(this, trace));
551 The view is now ready but we need a proper trace to test it. For this example, a trace was generated using LTTng-UST so that it would produce a sine function.<br>
553 [[Image:images/SampleView.png]]<br>
555 In summary, we have implemented a simple TMF view using the SWTChart library. We made use of signals and requests to populate the view at the appropriate time and we formated the time stamps nicely. We also made sure that the time stamp format is updated when the preferences change.
557 == TMF Built-in Views and Viewers ==
559 TMF provides base implementations for several types of views and viewers for generating custom X-Y-Charts, Time Graphs, or Trees. They are well integrated with various TMF features such as reading traces and time synchronization with other views. They also handle mouse events for navigating the trace and view, zooming or presenting detailed information at mouse position. The code can be found in the TMF UI plug-in ''org.eclipse.linuxtools.tmf.ui''. See below for a list of relevant java packages:
562 ** ''org.eclipse.linuxtools.tmf.ui.views'': Common TMF view base classes
564 ** ''org.eclipse.linuxtools.tmf.ui.viewers.xycharts'': Common base classes for X-Y-Chart viewers based on SWTChart
565 ** ''org.eclipse.linuxtools.tmf.ui.viewers.xycharts.barcharts'': Base classes for bar charts
566 ** ''org.eclipse.linuxtools.tmf.ui.viewers.xycharts.linecharts'': Base classes for line charts
568 ** ''org.eclipse.linuxtools.tmf.ui.widgets.timegraph'': Base classes for time graphs e.g. Gantt-charts
570 ** ''org.eclipse.linuxtools.tmf.ui.viewers.tree'': Base classes for TMF specific tree viewers
572 Several features in TMF and the Eclipse LTTng integration are using this framework and can be used as example for further developments:
574 ** ''org.eclipse.linuxtools.internal.lttng2.ust.ui.views.memusage.MemUsageView.java''
575 ** ''org.eclipse.linuxtools.internal.lttng2.kernel.ui.views.cpuusage.CpuUsageView.java''
576 ** ''org.eclipse.linuxtools.tracing.examples.ui.views.histogram.NewHistogramView.java''
578 ** ''org.eclipse.linuxtools.internal.lttng2.kernel.ui.views.controlflow.ControlFlowView.java''
579 ** ''org.eclipse.linuxtools.internal.lttng2.kernel.ui.views.resources.ResourcesView.java''
581 ** ''org.eclipse.linuxtools.tmf.ui.views.statesystem.TmfStateSystemExplorer.java''
582 ** ''org.eclipse.linuxtools.internal.lttng2.kernel.ui.views.cpuusage.CpuUsageComposite.java''
584 = Component Interaction =
586 TMF provides a mechanism for different components to interact with each other using signals. The signals can carry information that is specific to each signal.
588 The TMF Signal Manager handles registration of components and the broadcasting of signals to their intended receivers.
590 Components can register as VIP receivers which will ensure they will receive the signal before non-VIP receivers.
592 == Sending Signals ==
594 In order to send a signal, an instance of the signal must be created and passed as argument to the signal manager to be dispatched. Every component that can handle the signal will receive it. The receivers do not need to be known by the sender.
597 TmfExampleSignal signal = new TmfExampleSignal(this, ...);
598 TmfSignalManager.dispatchSignal(signal);
601 If the sender is an instance of the class TmfComponent, the broadcast method can be used:
604 TmfExampleSignal signal = new TmfExampleSignal(this, ...);
608 == Receiving Signals ==
610 In order to receive any signal, the receiver must first be registered with the signal manager. The receiver can register as a normal or VIP receiver.
613 TmfSignalManager.register(this);
614 TmfSignalManager.registerVIP(this);
617 If the receiver is an instance of the class TmfComponent, it is automatically registered as a normal receiver in the constructor.
619 When the receiver is destroyed or disposed, it should deregister itself from the signal manager.
622 TmfSignalManager.deregister(this);
625 To actually receive and handle any specific signal, the receiver must use the @TmfSignalHandler annotation and implement a method that will be called when the signal is broadcast. The name of the method is irrelevant.
629 public void example(TmfExampleSignal signal) {
634 The source of the signal can be used, if necessary, by a component to filter out and ignore a signal that was broadcast by itself when the component is also a receiver of the signal but only needs to handle it when it was sent by another component or another instance of the component.
636 == Signal Throttling ==
638 It is possible for a TmfComponent instance to buffer the dispatching of signals so that only the last signal queued after a specified delay without any other signal queued is sent to the receivers. All signals that are preempted by a newer signal within the delay are discarded.
640 The signal throttler must first be initialized:
643 final int delay = 100; // in ms
644 TmfSignalThrottler throttler = new TmfSignalThrottler(this, delay);
647 Then the sending of signals should be queued through the throttler:
650 TmfExampleSignal signal = new TmfExampleSignal(this, ...);
651 throttler.queue(signal);
654 When the throttler is no longer needed, it should be disposed:
660 == Signal Reference ==
662 The following is a list of built-in signals defined in the framework.
664 === TmfStartSynchSignal ===
668 This signal is used to indicate the start of broadcasting of a signal. Internally, the data provider will not fire event requests until the corresponding TmfEndSynchSignal signal is received. This allows coalescing of requests triggered by multiple receivers of the broadcast signal.
672 Sent by TmfSignalManager before dispatching a signal to all receivers.
676 Received by TmfDataProvider.
678 === TmfEndSynchSignal ===
682 This signal is used to indicate the end of broadcasting of a signal. Internally, the data provider fire all pending event requests that were received and buffered since the corresponding TmfStartSynchSignal signal was received. This allows coalescing of requests triggered by multiple receivers of the broadcast signal.
686 Sent by TmfSignalManager after dispatching a signal to all receivers.
690 Received by TmfDataProvider.
692 === TmfTraceOpenedSignal ===
696 This signal is used to indicate that a trace has been opened in an editor.
700 Sent by a TmfEventsEditor instance when it is created.
704 Received by TmfTrace, TmfExperiment, TmfTraceManager and every view that shows trace data. Components that show trace data should handle this signal.
706 === TmfTraceSelectedSignal ===
710 This signal is used to indicate that a trace has become the currently selected trace.
714 Sent by a TmfEventsEditor instance when it receives focus. Components can send this signal to make a trace editor be brought to front.
718 Received by TmfTraceManager and every view that shows trace data. Components that show trace data should handle this signal.
720 === TmfTraceClosedSignal ===
724 This signal is used to indicate that a trace editor has been closed.
728 Sent by a TmfEventsEditor instance when it is disposed.
732 Received by TmfTraceManager and every view that shows trace data. Components that show trace data should handle this signal.
734 === TmfTraceRangeUpdatedSignal ===
738 This signal is used to indicate that the valid time range of a trace has been updated. This triggers indexing of the trace up to the end of the range. In the context of streaming, this end time is considered a safe time up to which all events are guaranteed to have been completely received. For non-streaming traces, the end time is set to infinity indicating that all events can be read immediately. Any processing of trace events that wants to take advantage of request coalescing should be triggered by this signal.
742 Sent by TmfExperiment and non-streaming TmfTrace. Streaming traces should send this signal in the TmfTrace subclass when a new safe time is determined by a specific implementation.
746 Received by TmfTrace, TmfExperiment and components that process trace events. Components that need to process trace events should handle this signal.
748 === TmfTraceUpdatedSignal ===
752 This signal is used to indicate that new events have been indexed for a trace.
756 Sent by TmfCheckpointIndexer when new events have been indexed and the number of events has changed.
760 Received by components that need to be notified of a new trace event count.
762 === TmfTimeSynchSignal ===
766 This signal is used to indicate that a new time or time range has been
767 selected. It contains a begin and end time. If a single time is selected then
768 the begin and end time are the same.
772 Sent by any component that allows the user to select a time or time range.
776 Received by any component that needs to be notified of the currently selected time or time range.
778 === TmfRangeSynchSignal ===
782 This signal is used to indicate that a new time range window has been set.
786 Sent by any component that allows the user to set a time range window.
790 Received by any component that needs to be notified of the current visible time range window.
792 === TmfEventFilterAppliedSignal ===
796 This signal is used to indicate that a filter has been applied to a trace.
800 Sent by TmfEventsTable when a filter is applied.
804 Received by any component that shows trace data and needs to be notified of applied filters.
806 === TmfEventSearchAppliedSignal ===
810 This signal is used to indicate that a search has been applied to a trace.
814 Sent by TmfEventsTable when a search is applied.
818 Received by any component that shows trace data and needs to be notified of applied searches.
820 === TmfTimestampFormatUpdateSignal ===
824 This signal is used to indicate that the timestamp format preference has been updated.
828 Sent by TmfTimestampFormat when the default timestamp format preference is changed.
832 Received by any component that needs to refresh its display for the new timestamp format.
834 === TmfStatsUpdatedSignal ===
838 This signal is used to indicate that the statistics data model has been updated.
842 Sent by statistic providers when new statistics data has been processed.
846 Received by statistics viewers and any component that needs to be notified of a statistics update.
848 === TmfPacketStreamSelected ===
852 This signal is used to indicate that the user has selected a packet stream to analyze.
856 Sent by the Stream List View when the user selects a new packet stream.
860 Received by views that analyze packet streams.
864 TMF has built-in Eclipse tracing support for the debugging of signal interaction between components. To enable it, open the '''Run/Debug Configuration...''' dialog, select a configuration, click the '''Tracing''' tab, select the plug-in '''org.eclipse.linuxtools.tmf.core''', and check the '''signal''' item.
866 All signals sent and received will be logged to the file TmfTrace.log located in the Eclipse home directory.
868 = Generic State System =
872 The Generic State System is a utility available in TMF to track different states
873 over the duration of a trace. It works by first sending some or all events of
874 the trace into a state provider, which defines the state changes for a given
875 trace type. Once built, views and analysis modules can then query the resulting
876 database of states (called "state history") to get information.
878 For example, let's suppose we have the following sequence of events in a kernel
881 10 s, sys_open, fd = 5, file = /home/user/myfile
883 15 s, sys_read, fd = 5, size=32
885 20 s, sys_close, fd = 5
887 Now let's say we want to implement an analysis module which will track the
888 amount of bytes read and written to each file. Here, of course the sys_read is
889 interesting. However, by just looking at that event, we have no information on
890 which file is being read, only its fd (5) is known. To get the match
891 fd5 = /home/user/myfile, we have to go back to the sys_open event which happens
894 But since we don't know exactly where this sys_open event is, we will have to go
895 back to the very start of the trace, and look through events one by one! This is
896 obviously not efficient, and will not scale well if we want to analyze many
897 similar patterns, or for very large traces.
899 A solution in this case would be to use the state system to keep track of the
900 amount of bytes read/written to every *filename* (instead of every file
901 descriptor, like we get from the events). Then the module could ask the state
902 system "what is the amount of bytes read for file "/home/user/myfile" at time
903 16 s", and it would return the answer "32" (assuming there is no other read
906 == High-level components ==
908 The State System infrastructure is composed of 3 parts:
910 * The central state system
911 * The storage backend
913 The state provider is the customizable part. This is where the mapping from
914 trace events to state changes is done. This is what you want to implement for
915 your specific trace type and analysis type. It's represented by the
916 ITmfStateProvider interface (with a threaded implementation in
917 AbstractTmfStateProvider, which you can extend).
919 The core of the state system is exposed through the ITmfStateSystem and
920 ITmfStateSystemBuilder interfaces. The former allows only read-only access and
921 is typically used for views doing queries. The latter also allows writing to the
922 state history, and is typically used by the state provider.
924 Finally, each state system has its own separate backend. This determines how the
925 intervals, or the "state history", are saved (in RAM, on disk, etc.) You can
926 select the type of backend at construction time in the TmfStateSystemFactory.
930 Before we dig into how to use the state system, we should go over some useful
935 An attribute is the smallest element of the model that can be in any particular
936 state. When we refer to the "full state", in fact it means we are interested in
937 the state of every single attribute of the model.
939 === Attribute Tree ===
941 Attributes in the model can be placed in a tree-like structure, a bit like files
942 and directories in a file system. However, note that an attribute can always
943 have both a value and sub-attributes, so they are like files and directories at
944 the same time. We are then able to refer to every single attribute with its
947 For example, in the attribute tree for LTTng kernel traces, we use the following
948 attributes, among others:
966 In this model, the attribute "Processes/1000/PPID" refers to the PPID of process
967 with PID 1000. The attribute "CPUs/0/Status" represents the status (running,
968 idle, etc.) of CPU 0. "Processes/1000/PPID" and "Processes/1001/PPID" are two
969 different attribute, even though their base name is the same: the whole path is
970 the unique identifier.
972 The value of each attribute can change over the duration of the trace,
973 independently of the other ones, and independently of its position in the tree.
975 The tree-like organization is optional, all attributes could be at the same
976 level. But it's possible to put them in a tree, and it helps make things
981 In addition to a given path, each attribute also has a unique integer
982 identifier, called the "quark". To continue with the file system analogy, this
983 is like the inode number. When a new attribute is created, a new unique quark
984 will be assigned automatically. They are assigned incrementally, so they will
985 normally be equal to their order of creation, starting at 0.
987 Methods are offered to get the quark of an attribute from its path. The API
988 methods for inserting state changes and doing queries normally use quarks
989 instead of paths. This is to encourage users to cache the quarks and re-use
990 them, which avoids re-walking the attribute tree over and over, which avoids
991 unneeded hashing of strings.
995 The path and quark of an attribute will remain constant for the whole duration
996 of the trace. However, the value carried by the attribute will change. The value
997 of a specific attribute at a specific time is called the state value.
999 In the TMF implementation, state values can be integers, longs, doubles, or strings.
1000 There is also a "null value" type, which is used to indicate that no particular
1001 value is active for this attribute at this time, but without resorting to a
1004 Any other type of value could be used, as long as the backend knows how to store
1007 Note that the TMF implementation also forces every attribute to always carry the
1008 same type of state value. This is to make it simpler for views, so they can
1009 expect that an attribute will always use a given type, without having to check
1010 every single time. Null values are an exception, they are always allowed for all
1011 attributes, since they can safely be "unboxed" into all types.
1013 === State change ===
1015 A state change is the element that is inserted in the state system. It consists
1017 * a timestamp (the time at which the state change occurs)
1018 * an attribute (the attribute whose value will change)
1019 * a state value (the new value that the attribute will carry)
1021 It's not an object per se in the TMF implementation (it's represented by a
1022 function call in the state provider). Typically, the state provider will insert
1023 zero, one or more state changes for every trace event, depending on its event
1026 Note, we use "timestamp" here, but it's in fact a generic term that could be
1027 referred to as "index". For example, if a given trace type has no notion of
1028 timestamp, the event rank could be used.
1030 In the TMF implementation, the timestamp is a long (64-bit integer).
1032 === State interval ===
1034 State changes are inserted into the state system, but state intervals are the
1035 objects that come out on the other side. Those are stocked in the storage
1036 backend. A state interval represents a "state" of an attribute we want to track.
1037 When doing queries on the state system, intervals are what is returned. The
1038 components of a state interval are:
1044 The start and end times represent the time range of the state. The state value
1045 is the same as the state value in the state change that started this interval.
1046 The interval also keeps a reference to its quark, although you normally know
1047 your quark in advance when you do queries.
1049 === State history ===
1051 The state history is the name of the container for all the intervals created by
1052 the state system. The exact implementation (how the intervals are stored) is
1053 determined by the storage backend that is used.
1055 Some backends will use a state history that is peristent on disk, others do not.
1056 When loading a trace, if a history file is available and the backend supports
1057 it, it will be loaded right away, skipping the need to go through another
1060 === Construction phase ===
1062 Before we can query a state system, we need to build the state history first. To
1063 do so, trace events are sent one-by-one through the state provider, which in
1064 turn sends state changes to the central component, which then creates intervals
1065 and stores them in the backend. This is called the construction phase.
1067 Note that the state system needs to receive its events into chronological order.
1068 This phase will end once the end of the trace is reached.
1070 Also note that it is possible to query the state system while it is being build.
1071 Any timestamp between the start of the trace and the current end time of the
1072 state system (available with ITmfStateSystem#getCurrentEndTime()) is a valid
1073 timestamp that can be queried.
1077 As mentioned previously, when doing queries on the state system, the returned
1078 objects will be state intervals. In most cases it's the state *value* we are
1079 interested in, but since the backend has to instantiate the interval object
1080 anyway, there is no additional cost to return the interval instead. This way we
1081 also get the start and end times of the state "for free".
1083 There are two types of queries that can be done on the state system:
1085 ==== Full queries ====
1087 A full query means that we want to retrieve the whole state of the model for one
1088 given timestamp. As we remember, this means "the state of every single attribute
1089 in the model". As parameter we only need to pass the timestamp (see the API
1090 methods below). The return value will be an array of intervals, where the offset
1091 in the array represents the quark of each attribute.
1093 ==== Single queries ====
1095 In other cases, we might only be interested in the state of one particular
1096 attribute at one given timestamp. For these cases it's better to use a
1097 single query. For a single query. we need to pass both a timestamp and a
1098 quark in parameter. The return value will be a single interval, representing
1099 the state that this particular attribute was at that time.
1101 Single queries are typically faster than full queries (but once again, this
1102 depends on the backend that is used), but not by much. Even if you only want the
1103 state of say 10 attributes out of 200, it could be faster to use a full query
1104 and only read the ones you need. Single queries should be used for cases where
1105 you only want one attribute per timestamp (for example, if you follow the state
1106 of the same attribute over a time range).
1109 == Relevant interfaces/classes ==
1111 This section will describe the public interface and classes that can be used if
1112 you want to use the state system.
1114 === Main classes in org.eclipse.linuxtools.tmf.core.statesystem ===
1116 ==== ITmfStateProvider / AbstractTmfStateProvider ====
1118 ITmfStateProvider is the interface you have to implement to define your state
1119 provider. This is where most of the work has to be done to use a state system
1120 for a custom trace type or analysis type.
1122 For first-time users, it's recommended to extend AbstractTmfStateProvider
1123 instead. This class takes care of all the initialization mumbo-jumbo, and also
1124 runs the event handler in a separate thread. You will only need to implement
1125 eventHandle, which is the call-back that will be called for every event in the
1128 For an example, you can look at StatsStateProvider in the TMF tree, or at the
1129 small example below.
1131 ==== TmfStateSystemFactory ====
1133 Once you have defined your state provider, you need to tell your trace type to
1134 build a state system with this provider during its initialization. This consists
1135 of overriding TmfTrace#buildStateSystems() and in there of calling the method in
1136 TmfStateSystemFactory that corresponds to the storage backend you want to use
1137 (see the section [[#Comparison of state system backends]]).
1139 You will have to pass in parameter the state provider you want to use, which you
1140 should have defined already. Each backend can also ask for more configuration
1143 You must then call registerStateSystem(id, statesystem) to make your state
1144 system visible to the trace objects and the views. The ID can be any string of
1145 your choosing. To access this particular state system, the views or modules will
1146 need to use this ID.
1148 Also, don't forget to call super.buildStateSystems() in your implementation,
1149 unless you know for sure you want to skip the state providers built by the
1152 You can look at how LttngKernelTrace does it for an example. It could also be
1153 possible to build a state system only under certain conditions (like only if the
1154 trace contains certain event types).
1157 ==== ITmfStateSystem ====
1159 ITmfStateSystem is the main interface through which views or analysis modules
1160 will access the state system. It offers a read-only view of the state system,
1161 which means that no states can be inserted, and no attributes can be created.
1162 Calling TmfTrace#getStateSystems().get(id) will return you a ITmfStateSystem
1163 view of the requested state system. The main methods of interest are:
1165 ===== getQuarkAbsolute()/getQuarkRelative() =====
1167 Those are the basic quark-getting methods. The goal of the state system is to
1168 return the state values of given attributes at given timestamps. As we've seen
1169 earlier, attributes can be described with a file-system-like path. The goal of
1170 these methods is to convert from the path representation of the attribute to its
1173 Since quarks are created on-the-fly, there is no guarantee that the same
1174 attributes will have the same quark for two traces of the same type. The views
1175 should always query their quarks when dealing with a new trace or a new state
1176 provider. Beyond that however, quarks should be cached and reused as much as
1177 possible, to avoid potentially costly string re-hashing.
1179 getQuarkAbsolute() takes a variable amount of Strings in parameter, which
1180 represent the full path to the attribute. Some of them can be constants, some
1181 can come programatically, often from the event's fields.
1183 getQuarkRelative() is to be used when you already know the quark of a certain
1184 attribute, and want to access on of its sub-attributes. Its first parameter is
1185 the origin quark, followed by a String varagrs which represent the relative path
1186 to the final attribute.
1188 These two methods will throw an AttributeNotFoundException if trying to access
1189 an attribute that does not exist in the model.
1191 These methods also imply that the view has the knowledge of how the attribute
1192 tree is organized. This should be a reasonable hypothesis, since the same
1193 analysis plugin will normally ship both the state provider and the view, and
1194 they will have been written by the same person. In other cases, it's possible to
1195 use getSubAttributes() to explore the organization of the attribute tree first.
1197 ===== waitUntilBuilt() =====
1199 This is a simple method used to block the caller until the construction phase of
1200 this state system is done. If the view prefers to wait until all information is
1201 available before starting to do queries (to get all known attributes right away,
1202 for example), this is the guy to call.
1204 ===== queryFullState() =====
1206 This is the method to do full queries. As mentioned earlier, you only need to
1207 pass a target timestamp in parameter. It will return a List of state intervals,
1208 in which the offset corresponds to the attribute quark. This will represent the
1209 complete state of the model at the requested time.
1211 ===== querySingleState() =====
1213 The method to do single queries. You pass in parameter both a timestamp and an
1214 attribute quark. This will return the single state matching this
1215 timestamp/attribute pair.
1217 Other methods are available, you are encouraged to read their Javadoc and see if
1218 they can be potentially useful.
1220 ==== ITmfStateSystemBuilder ====
1222 ITmfStateSystemBuilder is the read-write interface to the state system. It
1223 extends ITmfStateSystem itself, so all its methods are available. It then adds
1224 methods that can be used to write to the state system, either by creating new
1225 attributes of inserting state changes.
1227 It is normally reserved for the state provider and should not be visible to
1228 external components. However it will be available in AbstractTmfStateProvider,
1229 in the field 'ss'. That way you can call ss.modifyAttribute() etc. in your state
1230 provider to write to the state.
1232 The main methods of interest are:
1234 ===== getQuark*AndAdd() =====
1236 getQuarkAbsoluteAndAdd() and getQuarkRelativeAndAdd() work exactly like their
1237 non-AndAdd counterparts in ITmfStateSystem. The difference is that the -AndAdd
1238 versions will not throw any exception: if the requested attribute path does not
1239 exist in the system, it will be created, and its newly-assigned quark will be
1242 When in a state provider, the -AndAdd version should normally be used (unless
1243 you know for sure the attribute already exist and don't want to create it
1244 otherwise). This means that there is no need to define the whole attribute tree
1245 in advance, the attributes will be created on-demand.
1247 ===== modifyAttribute() =====
1249 This is the main state-change-insertion method. As was explained before, a state
1250 change is defined by a timestamp, an attribute and a state value. Those three
1251 elements need to be passed to modifyAttribute as parameters.
1253 Other state change insertion methods are available (increment-, push-, pop- and
1254 removeAttribute()), but those are simply convenience wrappers around
1255 modifyAttribute(). Check their Javadoc for more information.
1257 ===== closeHistory() =====
1259 When the construction phase is done, do not forget to call closeHistory() to
1260 tell the backend that no more intervals will be received. Depending on the
1261 backend type, it might have to save files, close descriptors, etc. This ensures
1262 that a persitent file can then be re-used when the trace is opened again.
1264 If you use the AbstractTmfStateProvider, it will call closeHistory()
1265 automatically when it reaches the end of the trace.
1267 === Other relevant interfaces ===
1269 ==== o.e.l.tmf.core.statevalue.ITmfStateValue ====
1271 This is the interface used to represent state values. Those are used when
1272 inserting state changes in the provider, and is also part of the state intervals
1273 obtained when doing queries.
1275 The abstract TmfStateValue class contains the factory methods to create new
1276 state values of either int, long, double or string types. To retrieve the real
1277 object inside the state value, one can use the .unbox* methods.
1279 Note: Do not instantiate null values manually, use TmfStateValue.nullValue()
1281 ==== o.e.l.tmf.core.interval.ITmfStateInterval ====
1283 This is the interface to represent the state intervals, which are stored in the
1284 state history backend, and are returned when doing state system queries. A very
1285 simple implementation is available in TmfStateInterval. Its methods should be
1290 The following exceptions, found in o.e.l.tmf.core.exceptions, are related to
1291 state system activities.
1293 ==== AttributeNotFoundException ====
1295 This is thrown by getQuarkRelative() and getQuarkAbsolute() (but not byt the
1296 -AndAdd versions!) when passing an attribute path that is not present in the
1297 state system. This is to ensure that no new attribute is created when using
1298 these versions of the methods.
1300 Views can expect some attributes to be present, but they should handle these
1301 exceptions for when the attributes end up not being in the state system (perhaps
1302 this particular trace didn't have a certain type of events, etc.)
1304 ==== StateValueTypeException ====
1306 This exception will be thrown when trying to unbox a state value into a type
1307 different than its own. You should always check with ITmfStateValue#getType()
1308 beforehand if you are not sure about the type of a given state value.
1310 ==== TimeRangeException ====
1312 This exception is thrown when trying to do a query on the state system for a
1313 timestamp that is outside of its range. To be safe, you should check with
1314 ITmfStateSystem#getStartTime() and #getCurrentEndTime() for the current valid
1315 range of the state system. This is especially important when doing queries on
1316 a state system that is currently being built.
1318 ==== StateSystemDisposedException ====
1320 This exception is thrown when trying to access a state system that has been
1321 disposed, with its dispose() method. This can potentially happen at shutdown,
1322 since Eclipse is not always consistent with the order in which the components
1326 == Comparison of state system backends ==
1328 As we have seen in section [[#High-level components]], the state system needs
1329 a storage backend to save the intervals. Different implementations are
1330 available when building your state system from TmfStateSystemFactory.
1332 Do not confuse full/single queries with full/partial history! All backend types
1333 should be able to handle any type of queries defined in the ITmfStateSystem API,
1334 unless noted otherwise.
1336 === Full history ===
1338 Available with TmfStateSystemFactory#newFullHistory(). The full history uses a
1339 History Tree data structure, which is an optimized structure store state
1340 intervals on disk. Once built, it can respond to queries in a ''log(n)'' manner.
1342 You need to specify a file at creation time, which will be the container for
1343 the history tree. Once it's completely built, it will remain on disk (until you
1344 delete the trace from the project). This way it can be reused from one session
1345 to another, which makes subsequent loading time much faster.
1347 This the backend used by the LTTng kernel plugin. It offers good scalability and
1348 performance, even at extreme sizes (it's been tested with traces of sizes up to
1349 500 GB). Its main downside is the amount of disk space required: since every
1350 single interval is written to disk, the size of the history file can quite
1351 easily reach and even surpass the size of the trace itself.
1353 === Null history ===
1355 Available with TmfStateSystemFactory#newNullHistory(). As its name implies the
1356 null history is in fact an absence of state history. All its query methods will
1357 return null (see the Javadoc in NullBackend).
1359 Obviously, no file is required, and almost no memory space is used.
1361 It's meant to be used in cases where you are not interested in past states, but
1362 only in the "ongoing" one. It can also be useful for debugging and benchmarking.
1364 === In-memory history ===
1366 Available with TmfStateSystemFactory#newInMemHistory(). This is a simple wrapper
1367 using a TreeSet to store all state intervals in memory. The implementation at
1368 the moment is quite simple, it will perform a binary search on entries when
1369 doing queries to find the ones that match.
1371 The advantage of this method is that it's very quick to build and query, since
1372 all the information resides in memory. However, you are limited to 2^31 entries
1373 (roughly 2 billions), and depending on your state provider and trace type, that
1374 can happen really fast!
1376 There are no safeguards, so if you bust the limit you will end up with
1377 ArrayOutOfBoundsException's everywhere. If your trace or state history can be
1378 arbitrarily big, it's probably safer to use a Full History instead.
1380 === Partial history ===
1382 Available with TmfStateSystemFactory#newPartialHistory(). The partial history is
1383 a more advanced form of the full history. Instead of writing all state intervals
1384 to disk like with the full history, we only write a small fraction of them, and
1385 go back to read the trace to recreate the states in-between.
1387 It has a big advantage over a full history in terms of disk space usage. It's
1388 very possible to reduce the history tree file size by a factor of 1000, while
1389 keeping query times within a factor of two. Its main downside comes from the
1390 fact that you cannot do efficient single queries with it (they are implemented
1391 by doing full queries underneath).
1393 This makes it a poor choice for views like the Control Flow view, where you do
1394 a lot of range queries and single queries. However, it is a perfect fit for
1395 cases like statistics, where you usually do full queries already, and you store
1396 lots of small states which are very easy to "compress".
1398 However, it can't really be used until bug 409630 is fixed.
1400 == State System Operations ==
1402 TmfStateSystemOperations is a static class that implements additional
1403 statistical operations that can be performed on attributes of the state system.
1405 These operations require that the attribute be one of the numerical values
1406 (int, long or double).
1408 The speed of these operations can be greatly improved for large data sets if
1409 the attribute was inserted in the state system as a mipmap attribute. Refer to
1410 the [[#Mipmap feature | Mipmap feature]] section.
1412 ===== queryRangeMax() =====
1414 This method returns the maximum numerical value of an attribute in the
1415 specified time range. The attribute must be of type int, long or double.
1416 Null values are ignored. The returned value will be of the same state value
1417 type as the base attribute, or a null value if there is no state interval
1418 stored in the given time range.
1420 ===== queryRangeMin() =====
1422 This method returns the minimum numerical value of an attribute in the
1423 specified time range. The attribute must be of type int, long or double.
1424 Null values are ignored. The returned value will be of the same state value
1425 type as the base attribute, or a null value if there is no state interval
1426 stored in the given time range.
1428 ===== queryRangeAverage() =====
1430 This method returns the average numerical value of an attribute in the
1431 specified time range. The attribute must be of type int, long or double.
1432 Each state interval value is weighted according to time. Null values are
1433 counted as zero. The returned value will be a double primitive, which will
1434 be zero if there is no state interval stored in the given time range.
1438 Here is a small example of code that will use the state system. For this
1439 example, let's assume we want to track the state of all the CPUs in a LTTng
1440 kernel trace. To do so, we will watch for the "sched_switch" event in the state
1441 provider, and will update an attribute indicating if the associated CPU should
1442 be set to "running" or "idle".
1444 We will use an attribute tree that looks like this:
1458 The second-level attributes will be named from the information available in the
1459 trace events. Only the "Status" attributes will carry a state value (this means
1460 we could have just used "1", "2", "3",... directly, but we'll do it in a tree
1461 for the example's sake).
1463 Also, we will use integer state values to represent "running" or "idle", instead
1464 of saving the strings that would get repeated every time. This will help in
1465 reducing the size of the history file.
1467 First we will define a state provider in MyStateProvider. Then, assuming we
1468 have already implemented a custom trace type extending CtfTmfTrace, we will add
1469 a section to it to make it build a state system using the provider we defined
1470 earlier. Finally, we will show some example code that can query the state
1471 system, which would normally go in a view or analysis module.
1473 === State Provider ===
1476 import org.eclipse.linuxtools.tmf.core.ctfadaptor.CtfTmfEvent;
1477 import org.eclipse.linuxtools.tmf.core.event.ITmfEvent;
1478 import org.eclipse.linuxtools.tmf.core.exceptions.AttributeNotFoundException;
1479 import org.eclipse.linuxtools.tmf.core.exceptions.StateValueTypeException;
1480 import org.eclipse.linuxtools.tmf.core.exceptions.TimeRangeException;
1481 import org.eclipse.linuxtools.tmf.core.statesystem.AbstractTmfStateProvider;
1482 import org.eclipse.linuxtools.tmf.core.statevalue.ITmfStateValue;
1483 import org.eclipse.linuxtools.tmf.core.statevalue.TmfStateValue;
1484 import org.eclipse.linuxtools.tmf.core.trace.ITmfTrace;
1487 * Example state system provider.
1489 * @author Alexandre Montplaisir
1491 public class MyStateProvider extends AbstractTmfStateProvider {
1493 /** State value representing the idle state */
1494 public static ITmfStateValue IDLE = TmfStateValue.newValueInt(0);
1496 /** State value representing the running state */
1497 public static ITmfStateValue RUNNING = TmfStateValue.newValueInt(1);
1503 * The trace to which this state provider is associated
1505 public MyStateProvider(ITmfTrace trace) {
1506 super(trace, CtfTmfEvent.class, "Example"); //$NON-NLS-1$
1508 * The third parameter here is not important, it's only used to name a
1509 * thread internally.
1514 public int getVersion() {
1516 * If the version of an existing file doesn't match the version supplied
1517 * in the provider, a rebuild of the history will be forced.
1523 public MyStateProvider getNewInstance() {
1524 return new MyStateProvider(getTrace());
1528 protected void eventHandle(ITmfEvent ev) {
1530 * AbstractStateChangeInput should have already checked for the correct
1533 CtfTmfEvent event = (CtfTmfEvent) ev;
1535 final long ts = event.getTimestamp().getValue();
1536 Integer nextTid = ((Long) event.getContent().getField("next_tid").getValue()).intValue();
1540 if (event.getEventName().equals("sched_switch")) {
1541 int quark = ss.getQuarkAbsoluteAndAdd("CPUs", String.valueOf(event.getCPU()), "Status");
1542 ITmfStateValue value;
1548 ss.modifyAttribute(ts, value, quark);
1551 } catch (TimeRangeException e) {
1553 * This should not happen, since the timestamp comes from a trace
1556 throw new IllegalStateException(e);
1557 } catch (AttributeNotFoundException e) {
1559 * This should not happen either, since we're only accessing a quark
1562 throw new IllegalStateException(e);
1563 } catch (StateValueTypeException e) {
1565 * This wouldn't happen here, but could potentially happen if we try
1566 * to insert mismatching state value types in the same attribute.
1568 e.printStackTrace();
1576 === Trace type definition ===
1579 import java.io.File;
1581 import org.eclipse.core.resources.IProject;
1582 import org.eclipse.core.runtime.IStatus;
1583 import org.eclipse.core.runtime.Status;
1584 import org.eclipse.linuxtools.tmf.core.ctfadaptor.CtfTmfTrace;
1585 import org.eclipse.linuxtools.tmf.core.exceptions.TmfTraceException;
1586 import org.eclipse.linuxtools.tmf.core.statesystem.ITmfStateProvider;
1587 import org.eclipse.linuxtools.tmf.core.statesystem.ITmfStateSystem;
1588 import org.eclipse.linuxtools.tmf.core.statesystem.TmfStateSystemFactory;
1589 import org.eclipse.linuxtools.tmf.core.trace.TmfTraceManager;
1592 * Example of a custom trace type using a custom state provider.
1594 * @author Alexandre Montplaisir
1596 public class MyTraceType extends CtfTmfTrace {
1598 /** The file name of the history file */
1599 public final static String HISTORY_FILE_NAME = "mystatefile.ht";
1601 /** ID of the state system we will build */
1602 public static final String STATE_ID = "org.eclipse.linuxtools.lttng2.example";
1605 * Default constructor
1607 public MyTraceType() {
1612 public IStatus validate(final IProject project, final String path) {
1614 * Add additional validation code here, and return a IStatus.ERROR if
1617 return Status.OK_STATUS;
1621 protected void buildStateSystem() throws TmfTraceException {
1622 super.buildStateSystem();
1624 /* Build the custom state system for this trace */
1625 String directory = TmfTraceManager.getSupplementaryFileDir(this);
1626 final File htFile = new File(directory + HISTORY_FILE_NAME);
1627 final ITmfStateProvider htInput = new MyStateProvider(this);
1629 ITmfStateSystem ss = TmfStateSystemFactory.newFullHistory(htFile, htInput, false);
1630 fStateSystems.put(STATE_ID, ss);
1639 import java.util.List;
1641 import org.eclipse.linuxtools.tmf.core.exceptions.AttributeNotFoundException;
1642 import org.eclipse.linuxtools.tmf.core.exceptions.StateSystemDisposedException;
1643 import org.eclipse.linuxtools.tmf.core.exceptions.TimeRangeException;
1644 import org.eclipse.linuxtools.tmf.core.interval.ITmfStateInterval;
1645 import org.eclipse.linuxtools.tmf.core.statesystem.ITmfStateSystem;
1646 import org.eclipse.linuxtools.tmf.core.statevalue.ITmfStateValue;
1647 import org.eclipse.linuxtools.tmf.core.trace.ITmfTrace;
1650 * Class showing examples of state system queries.
1652 * @author Alexandre Montplaisir
1654 public class QueryExample {
1656 private final ITmfStateSystem ss;
1662 * Trace that this "view" will display.
1664 public QueryExample(ITmfTrace trace) {
1665 ss = trace.getStateSystems().get(MyTraceType.STATE_ID);
1669 * Example method of querying one attribute in the state system.
1671 * We pass it a cpu and a timestamp, and it returns us if that cpu was
1672 * executing a process (true/false) at that time.
1677 * The timestamp of the query
1678 * @return True if the CPU was running, false otherwise
1680 public boolean cpuIsRunning(int cpu, long timestamp) {
1682 int quark = ss.getQuarkAbsolute("CPUs", String.valueOf(cpu), "Status");
1683 ITmfStateValue value = ss.querySingleState(timestamp, quark).getStateValue();
1685 if (value.equals(MyStateProvider.RUNNING)) {
1690 * Since at this level we have no guarantee on the contents of the state
1691 * system, it's important to handle these cases correctly.
1693 } catch (AttributeNotFoundException e) {
1695 * Handle the case where the attribute does not exist in the state
1696 * system (no CPU with this number, etc.)
1699 } catch (TimeRangeException e) {
1701 * Handle the case where 'timestamp' is outside of the range of the
1705 } catch (StateSystemDisposedException e) {
1707 * Handle the case where the state system is being disposed. If this
1708 * happens, it's normally when shutting down, so the view can just
1709 * return immediately and wait it out.
1717 * Example method of using a full query.
1719 * We pass it a timestamp, and it returns us how many CPUs were executing a
1720 * process at that moment.
1723 * The target timestamp
1724 * @return The amount of CPUs that were running at that time
1726 public int getNbRunningCpus(long timestamp) {
1730 /* Get the list of the quarks we are interested in. */
1731 List<Integer> quarks = ss.getQuarks("CPUs", "*", "Status");
1734 * Get the full state at our target timestamp (it's better than
1735 * doing an arbitrary number of single queries).
1737 List<ITmfStateInterval> state = ss.queryFullState(timestamp);
1739 /* Look at the value of the state for each quark */
1740 for (Integer quark : quarks) {
1741 ITmfStateValue value = state.get(quark).getStateValue();
1742 if (value.equals(MyStateProvider.RUNNING)) {
1747 } catch (TimeRangeException e) {
1749 * Handle the case where 'timestamp' is outside of the range of the
1753 } catch (StateSystemDisposedException e) {
1754 /* Handle the case where the state system is being disposed. */
1762 == Mipmap feature ==
1764 The mipmap feature allows attributes to be inserted into the state system with
1765 additional computations performed to automatically store sub-attributes that
1766 can later be used for statistical operations. The mipmap has a resolution which
1767 represents the number of state attribute changes that are used to compute the
1768 value at the next mipmap level.
1770 The supported mipmap features are: max, min, and average. Each one of these
1771 features requires that the base attribute be a numerical state value (int, long
1772 or double). An attribute can be mipmapped for one or more of the features at
1775 To use a mipmapped attribute in queries, call the corresponding methods of the
1776 static class [[#State System Operations | TmfStateSystemOperations]].
1778 === AbstractTmfMipmapStateProvider ===
1780 AbstractTmfMipmapStateProvider is an abstract provider class that allows adding
1781 features to a specific attribute into a mipmap tree. It extends AbstractTmfStateProvider.
1783 If a provider wants to add mipmapped attributes to its tree, it must extend
1784 AbstractTmfMipmapStateProvider and call modifyMipmapAttribute() in the event
1785 handler, specifying one or more mipmap features to compute. Then the structure
1786 of the attribute tree will be :
1790 | |- <mipmapFeature> (min/max/avg)
1795 | | |- n (maximum mipmap level)
1796 | |- <mipmapFeature> (min/max/avg)
1801 | | |- n (maximum mipmap level)
1805 = UML2 Sequence Diagram Framework =
1807 The purpose of the UML2 Sequence Diagram Framework of TMF is to provide a framework for generation of UML2 sequence diagrams. It provides
1808 *UML2 Sequence diagram drawing capabilities (i.e. lifelines, messages, activations, object creation and deletion)
1809 *a generic, re-usable Sequence Diagram View
1810 *Eclipse Extension Point for the creation of sequence diagrams
1811 *callback hooks for searching and filtering within the Sequence Diagram View
1813 The following chapters describe the Sequence Diagram Framework as well as a reference implementation and its usage.
1815 == TMF UML2 Sequence Diagram Extensions ==
1817 In the UML2 Sequence Diagram Framework an Eclipse extension point is defined so that other plug-ins can contribute code to create sequence diagram.
1819 '''Identifier''': org.eclipse.linuxtools.tmf.ui.uml2SDLoader<br>
1820 '''Since''': 1.0<br>
1821 '''Description''': This extension point aims to list and connect any UML2 Sequence Diagram loader.<br>
1822 '''Configuration Markup''':<br>
1825 <!ELEMENT extension (uml2SDLoader)+>
1827 point CDATA #REQUIRED
1833 *point - A fully qualified identifier of the target extension point.
1834 *id - An optional identifier of the extension instance.
1835 *name - An optional name of the extension instance.
1838 <!ELEMENT uml2SDLoader EMPTY>
1839 <!ATTLIST uml2SDLoader
1841 name CDATA #REQUIRED
1842 class CDATA #REQUIRED
1843 view CDATA #REQUIRED
1844 default (true | false)
1847 *id - A unique identifier for this uml2SDLoader. This is not mandatory as long as the id attribute cannot be retrieved by the provider plug-in. The class attribute is the one on which the underlying algorithm relies.
1848 *name - An name of the extension instance.
1849 *class - The implementation of this UML2 SD viewer loader. The class must implement org.eclipse.linuxtools.tmf.ui.views.uml2sd.load.IUml2SDLoader.
1850 *view - The view ID of the view that this loader aims to populate. Either org.eclipse.linuxtools.tmf.ui.views.uml2sd.SDView itself or a extension of org.eclipse.linuxtools.tmf.ui.views.uml2sd.SDView.
1851 *default - Set to true to make this loader the default one for the view; in case of several default loaders, first one coming from extensions list is taken.
1854 == Management of the Extension Point ==
1856 The TMF UI plug-in is responsible for evaluating each contribution to the extension point.
1859 With this extension point, a loader class is associated with a Sequence Diagram View. Multiple loaders can be associated to a single Sequence Diagram View. However, additional means have to be implemented to specify which loader should be used when opening the view. For example, an eclipse action or command could be used for that. This additional code is not necessary if there is only one loader for a given Sequence Diagram View associated and this loader has the attribute "default" set to "true". (see also [[#Using one Sequence Diagram View with Multiple Loaders | Using one Sequence Diagram View with Multiple Loaders]])
1861 == Sequence Diagram View ==
1863 For this extension point a Sequence Diagram View has to be defined as well. The Sequence Diagram View class implementation is provided by the plug-in ''org.eclipse.linuxtools.tmf.ui'' (''org.eclipse.linuxtools.tmf.ui.views.uml2sd.SDView'') and can be used as is or can also be sub-classed. For that, a view extension has to be added to the ''plugin.xml''.
1865 === Supported Widgets ===
1867 The loader class provides a frame containing all the UML2 widgets to be displayed. The following widgets exist:
1871 *Synchronous Message
1872 *Asynchronous Message
1873 *Synchronous Message Return
1874 *Asynchronous Message Return
1877 For a lifeline, a category can be defined. The lifeline category defines icons, which are displayed in the lifeline header.
1881 The Sequence Diagram View allows the user to zoom in, zoom out and reset the zoom factor.
1885 It is possible to print the whole sequence diagram as well as part of it.
1887 === Key Bindings ===
1889 *SHIFT+ALT+ARROW-DOWN - to scroll down within sequence diagram one view page at a time
1890 *SHIFT+ALT+ARROW-UP - to scroll up within sequence diagram one view page at a time
1891 *SHIFT+ALT+ARROW-RIGHT - to scroll right within sequence diagram one view page at a time
1892 *SHIFT+ALT+ARROW-LEFT - to scroll left within sequence diagram one view page at a time
1893 *SHIFT+ALT+ARROW-HOME - to jump to the beginning of the selected message if not already visible in page
1894 *SHIFT+ALT+ARROW-END - to jump to the end of the selected message if not already visible in page
1895 *CTRL+F - to open find dialog if either the basic or extended find provider is defined (see [[#Using the Find Provider Interface | Using the Find Provider Interface]])
1896 *CTRL+P - to open print dialog
1900 The UML2 Sequence Diagram Framework provides preferences to customize the appearance of the Sequence Diagram View. The color of all widgets and text as well as the fonts of the text of all widget can be adjust. Amongst others the default lifeline width can be alternated. To change preferences select '''Windows->Preferences->Tracing->UML2 Sequence Diagrams'''. The following preference page will show:<br>
1901 [[Image:images/SeqDiagramPref.png]] <br>
1902 After changing the preferences select '''OK'''.
1904 === Callback hooks ===
1906 The Sequence Diagram View provides several callback hooks so that extension can provide application specific functionality. The following interfaces can be provided:
1907 * Basic find provider or extended find Provider<br> For finding within the sequence diagram
1908 * Basic filter provider and extended Filter Provider<br> For filtering within the sequnce diagram.
1909 * Basic paging provider or advanced paging provider<br> For scalability reasons, used to limit number of displayed messages
1910 * Properies provider<br> To provide properties of selected elements
1911 * Collapse provider <br> To collapse areas of the sequence diagram
1915 This tutorial describes how to create a UML2 Sequence Diagram Loader extension and use this loader in the in Eclipse.
1917 === Prerequisites ===
1919 The tutorial is based on Eclipse 4.4 (Eclipse Luna) and TMF 3.0.0.
1921 === Creating an Eclipse UI Plug-in ===
1923 To create a new project with name org.eclipse.linuxtools.tmf.sample.ui select '''File -> New -> Project -> Plug-in Development -> Plug-in Project'''. <br>
1924 [[Image:images/Screenshot-NewPlug-inProject1.png]]<br>
1926 [[Image:images/Screenshot-NewPlug-inProject2.png]]<br>
1928 [[Image:images/Screenshot-NewPlug-inProject3.png]]<br>
1930 === Creating a Sequence Diagram View ===
1932 To open the plug-in manifest, double-click on the MANIFEST.MF file. <br>
1933 [[Image:images/SelectManifest.png]]<br>
1935 Change to the Dependencies tab and select '''Add...''' of the ''Required Plug-ins'' section. A new dialog box will open. Next find plug-ins ''org.eclipse.linuxtools.tmf.ui'' and ''org.eclipse.linuxtools.tmf.core'' and then press '''OK'''<br>
1936 [[Image:images/AddDependencyTmfUi.png]]<br>
1938 Change to the Extensions tab and select '''Add...''' of the ''All Extension'' section. A new dialog box will open. Find the view extension ''org.eclipse.ui.views'' and press '''Finish'''.<br>
1939 [[Image:images/AddViewExtension1.png]]<br>
1941 To create a Sequence Diagram View, click the right mouse button. Then select '''New -> view'''<br>
1942 [[Image:images/AddViewExtension2.png]]<br>
1944 A new view entry has been created. Fill in the fields ''id'', ''name'' and ''class''. Note that for ''class'' the SD view implementation (''org.eclipse.linuxtools.tmf.ui.views.SDView'') of the TMF UI plug-in is used.<br>
1945 [[Image:images/FillSampleSeqDiagram.png]]<br>
1947 The view is prepared. Run the Example. To launch the an Eclipse Application select the ''Overview'' tab and click on '''Launch an Eclipse Application'''<br>
1948 [[Image:images/RunEclipseApplication.png]]<br>
1950 A new Eclipse application window will show. In the new window go to '''Windows -> Show View -> Other... -> Other -> Sample Sequence Diagram'''.<br>
1951 [[Image:images/ShowViewOther.png]]<br>
1953 The Sequence Diagram View will open with an blank page.<br>
1954 [[Image:images/BlankSampleSeqDiagram.png]]<br>
1956 Close the Example Application.
1958 === Defining the uml2SDLoader Extension ===
1960 After defining the Sequence Diagram View it's time to create the ''uml2SDLoader'' Extension. <br>
1962 Before doing that add a dependency to TMF. For that select '''Add...''' of the ''Required Plug-ins'' section. A new dialog box will open. Next find plug-in ''org.eclipse.linuxtools.tmf'' and press '''OK'''<br>
1963 [[Image:images/AddDependencyTmf.png]]<br>
1965 To create the loader extension, change to the Extensions tab and select '''Add...''' of the ''All Extension'' section. A new dialog box will open. Find the extension ''org.eclipse.linuxtools.tmf.ui.uml2SDLoader'' and press '''Finish'''.<br>
1966 [[Image:images/AddTmfUml2SDLoader.png]]<br>
1968 A new 'uml2SDLoader'' extension has been created. Fill in fields ''id'', ''name'', ''class'', ''view'' and ''default''. Use ''default'' equal true for this example. For the view add the id of the Sequence Diagram View of chapter [[#Creating a Sequence Diagram View | Creating a Sequence Diagram View]]. <br>
1969 [[Image:images/FillSampleLoader.png]]<br>
1971 Then click on ''class'' (see above) to open the new class dialog box. Fill in the relevant fields and select '''Finish'''. <br>
1972 [[Image:images/NewSampleLoaderClass.png]]<br>
1974 A new Java class will be created which implements the interface ''org.eclipse.linuxtools.tmf.ui.views.uml2sd.load.IUml2SDLoader''.<br>
1977 package org.eclipse.linuxtools.tmf.sample.ui;
1979 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.SDView;
1980 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.load.IUml2SDLoader;
1982 public class SampleLoader implements IUml2SDLoader {
1984 public SampleLoader() {
1985 // TODO Auto-generated constructor stub
1989 public void dispose() {
1990 // TODO Auto-generated method stub
1995 public String getTitleString() {
1996 // TODO Auto-generated method stub
2001 public void setViewer(SDView arg0) {
2002 // TODO Auto-generated method stub
2007 === Implementing the Loader Class ===
2009 Next is to implement the methods of the IUml2SDLoader interface method. The following code snippet shows how to create the major sequence diagram elements. Please note that no time information is stored.<br>
2012 package org.eclipse.linuxtools.tmf.sample.ui;
2014 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.SDView;
2015 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.AsyncMessage;
2016 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.AsyncMessageReturn;
2017 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.ExecutionOccurrence;
2018 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.Frame;
2019 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.Lifeline;
2020 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.Stop;
2021 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.SyncMessage;
2022 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.core.SyncMessageReturn;
2023 import org.eclipse.linuxtools.tmf.ui.views.uml2sd.load.IUml2SDLoader;
2025 public class SampleLoader implements IUml2SDLoader {
2027 private SDView fSdView;
2029 public SampleLoader() {
2033 public void dispose() {
2037 public String getTitleString() {
2038 return "Sample Diagram";
2042 public void setViewer(SDView arg0) {
2047 private void createFrame() {
2049 Frame testFrame = new Frame();
2050 testFrame.setName("Sample Frame");
2056 Lifeline lifeLine1 = new Lifeline();
2057 lifeLine1.setName("Object1");
2058 testFrame.addLifeLine(lifeLine1);
2060 Lifeline lifeLine2 = new Lifeline();
2061 lifeLine2.setName("Object2");
2062 testFrame.addLifeLine(lifeLine2);
2066 * Create Sync Message
2068 // Get new occurrence on lifelines
2069 lifeLine1.getNewEventOccurrence();
2071 // Get Sync message instances
2072 SyncMessage start = new SyncMessage();
2073 start.setName("Start");
2074 start.setEndLifeline(lifeLine1);
2075 testFrame.addMessage(start);
2078 * Create Sync Message
2080 // Get new occurrence on lifelines
2081 lifeLine1.getNewEventOccurrence();
2082 lifeLine2.getNewEventOccurrence();
2084 // Get Sync message instances
2085 SyncMessage syn1 = new SyncMessage();
2086 syn1.setName("Sync Message 1");
2087 syn1.setStartLifeline(lifeLine1);
2088 syn1.setEndLifeline(lifeLine2);
2089 testFrame.addMessage(syn1);
2092 * Create corresponding Sync Message Return
2095 // Get new occurrence on lifelines
2096 lifeLine1.getNewEventOccurrence();
2097 lifeLine2.getNewEventOccurrence();
2099 SyncMessageReturn synReturn1 = new SyncMessageReturn();
2100 synReturn1.setName("Sync Message Return 1");
2101 synReturn1.setStartLifeline(lifeLine2);
2102 synReturn1.setEndLifeline(lifeLine1);
2103 synReturn1.setMessage(syn1);
2104 testFrame.addMessage(synReturn1);
2107 * Create Activations (Execution Occurrence)
2109 ExecutionOccurrence occ1 = new ExecutionOccurrence();
2110 occ1.setStartOccurrence(start.getEventOccurrence());
2111 occ1.setEndOccurrence(synReturn1.getEventOccurrence());
2112 lifeLine1.addExecution(occ1);
2113 occ1.setName("Activation 1");
2115 ExecutionOccurrence occ2 = new ExecutionOccurrence();
2116 occ2.setStartOccurrence(syn1.getEventOccurrence());
2117 occ2.setEndOccurrence(synReturn1.getEventOccurrence());
2118 lifeLine2.addExecution(occ2);
2119 occ2.setName("Activation 2");
2122 * Create Sync Message
2124 // Get new occurrence on lifelines
2125 lifeLine1.getNewEventOccurrence();
2126 lifeLine2.getNewEventOccurrence();
2128 // Get Sync message instances
2129 AsyncMessage asyn1 = new AsyncMessage();
2130 asyn1.setName("Async Message 1");
2131 asyn1.setStartLifeline(lifeLine1);
2132 asyn1.setEndLifeline(lifeLine2);
2133 testFrame.addMessage(asyn1);
2136 * Create corresponding Sync Message Return
2139 // Get new occurrence on lifelines
2140 lifeLine1.getNewEventOccurrence();
2141 lifeLine2.getNewEventOccurrence();
2143 AsyncMessageReturn asynReturn1 = new AsyncMessageReturn();
2144 asynReturn1.setName("Async Message Return 1");
2145 asynReturn1.setStartLifeline(lifeLine2);
2146 asynReturn1.setEndLifeline(lifeLine1);
2147 asynReturn1.setMessage(asyn1);
2148 testFrame.addMessage(asynReturn1);
2154 // Get new occurrence on lifelines
2155 lifeLine1.getNewEventOccurrence();
2157 EllipsisMessage info = new EllipsisMessage();
2158 info.setName("Object deletion");
2159 info.setStartLifeline(lifeLine2);
2160 testFrame.addNode(info);
2165 Stop stop = new Stop();
2166 stop.setLifeline(lifeLine2);
2167 stop.setEventOccurrence(lifeLine2.getNewEventOccurrence());
2168 lifeLine2.addNode(stop);
2170 fSdView.setFrame(testFrame);
2175 Now it's time to run the example application. To launch the Example Application select the ''Overview'' tab and click on '''Launch an Eclipse Application'''<br>
2176 [[Image:images/SampleDiagram1.png]] <br>
2178 === Adding time information ===
2180 To add time information in sequence diagram the timestamp has to be set for each message. The sequence diagram framework uses the ''TmfTimestamp'' class of plug-in ''org.eclipse.linuxtools.tmf.core''. Use ''setTime()'' on each message ''SyncMessage'' since start and end time are the same. For each ''AsyncMessage'' set start and end time separately by using methods ''setStartTime'' and ''setEndTime''. For example: <br>
2183 private void createFrame() {
2185 start.setTime(new TmfTimestamp(1000, -3));
2186 syn1.setTime(new TmfTimestamp(1005, -3));
2187 synReturn1.setTime(new TmfTimestamp(1050, -3));
2188 asyn1.setStartTime(new TmfTimestamp(1060, -3));
2189 asyn1.setEndTime(new TmfTimestamp(1070, -3));
2190 asynReturn1.setStartTime(new TmfTimestamp(1060, -3));
2191 asynReturn1.setEndTime(new TmfTimestamp(1070, -3));
2196 When running the example application, a time compression bar on the left appears which indicates the time elapsed between consecutive events. The time compression scale shows where the time falls between the minimum and maximum delta times. The intensity of the color is used to indicate the length of time, namely, the deeper the intensity, the higher the delta time. The minimum and maximum delta times are configurable through the collbar menu ''Configure Min Max''. The time compression bar and scale may provide an indication about which events consumes the most time. By hovering over the time compression bar a tooltip appears containing more information. <br>
2198 [[Image:images/SampleDiagramTimeComp.png]] <br>
2200 By hovering over a message it will show the time information in the appearing tooltip. For each ''SyncMessage'' it shows its time occurrence and for each ''AsyncMessage'' it shows the start and end time.
2202 [[Image:images/SampleDiagramSyncMessage.png]] <br>
2203 [[Image:images/SampleDiagramAsyncMessage.png]] <br>
2205 To see the time elapsed between 2 messages, select one message and hover over a second message. A tooltip will show with the delta in time. Note if the second message is before the first then a negative delta is displayed. Note that for ''AsyncMessage'' the end time is used for the delta calculation.<br>
2206 [[Image:images/SampleDiagramMessageDelta.png]] <br>
2208 === Default Coolbar and Menu Items ===
2210 The Sequence Diagram View comes with default coolbar and menu items. By default, each sequence diagram shows the following actions:
2215 * Configure Min Max (drop-down menu only)
2216 * Navigation -> Show the node end (drop-down menu only)
2217 * Navigation -> Show the node start (drop-down menu only)
2219 [[Image:images/DefaultCoolbarMenu.png]]<br>
2221 === Implementing Optional Callbacks ===
2223 The following chapters describe how to use all supported provider interfaces.
2225 ==== Using the Paging Provider Interface ====
2227 For scalability reasons, the paging provider interfaces exists to limit the number of messages displayed in the Sequence Diagram View at a time. For that, two interfaces exist, the basic paging provider and the advanced paging provider. When using the basic paging interface, actions for traversing page by page through the sequence diagram of a trace will be provided.
2229 To use the basic paging provider, first the interface methods of the ''ISDPagingProvider'' have to be implemented by a class. (i.e. ''hasNextPage()'', ''hasPrevPage()'', ''nextPage()'', ''prevPage()'', ''firstPage()'' and ''endPage()''. Typically, this is implemented in the loader class. Secondly, the provider has to be set in the Sequence Diagram View. This will be done in the ''setViewer()'' method of the loader class. Lastly, the paging provider has to be removed from the view, when the ''dispose()'' method of the loader class is called.
2232 public class SampleLoader implements IUml2SDLoader, ISDPagingProvider {
2237 public void dispose() {
2238 if (fSdView != null) {
2239 fSdView.resetProviders();
2244 public void setViewer(SDView arg0) {
2246 fSdView.setSDPagingProvider(this);
2250 private void createSecondFrame() {
2251 Frame testFrame = new Frame();
2252 testFrame.setName("SecondFrame");
2253 Lifeline lifeline = new Lifeline();
2254 lifeline.setName("LifeLine 0");
2255 testFrame.addLifeLine(lifeline);
2256 lifeline = new Lifeline();
2257 lifeline.setName("LifeLine 1");
2258 testFrame.addLifeLine(lifeline);
2259 for (int i = 1; i < 5; i++) {
2260 SyncMessage message = new SyncMessage();
2261 message.autoSetStartLifeline(testFrame.getLifeline(0));
2262 message.autoSetEndLifeline(testFrame.getLifeline(0));
2263 message.setName((new StringBuilder("Message ")).append(i).toString());
2264 testFrame.addMessage(message);
2266 SyncMessageReturn messageReturn = new SyncMessageReturn();
2267 messageReturn.autoSetStartLifeline(testFrame.getLifeline(0));
2268 messageReturn.autoSetEndLifeline(testFrame.getLifeline(0));
2270 testFrame.addMessage(messageReturn);
2271 messageReturn.setName((new StringBuilder("Message return ")).append(i).toString());
2272 ExecutionOccurrence occ = new ExecutionOccurrence();
2273 occ.setStartOccurrence(testFrame.getSyncMessage(i - 1).getEventOccurrence());
2274 occ.setEndOccurrence(testFrame.getSyncMessageReturn(i - 1).getEventOccurrence());
2275 testFrame.getLifeline(0).addExecution(occ);
2277 fSdView.setFrame(testFrame);
2281 public boolean hasNextPage() {
2286 public boolean hasPrevPage() {
2291 public void nextPage() {
2293 createSecondFrame();
2297 public void prevPage() {
2303 public void firstPage() {
2309 public void lastPage() {
2311 createSecondFrame();
2318 When running the example application, new actions will be shown in the coolbar and the coolbar menu. <br>
2320 [[Image:images/PageProviderAdded.png]]
2323 To use the advanced paging provider, the interface ''ISDAdvancePagingProvider'' has to be implemented. It extends the basic paging provider. The methods ''currentPage()'', ''pagesCount()'' and ''pageNumberChanged()'' have to be added.
2326 ==== Using the Find Provider Interface ====
2328 For finding nodes in a sequence diagram two interfaces exists. One for basic finding and one for extended finding. The basic find comes with a dialog box for entering find criteria as regular expressions. This find criteria can be used to execute the find. Find criteria a persisted in the Eclipse workspace.
2330 For the extended find provider interface a ''org.eclipse.jface.action.Action'' class has to be provided. The actual find handling has to be implemented and triggered by the action.
2332 Only on at a time can be active. If the extended find provder is defined it obsoletes the basic find provider.
2334 To use the basic find provider, first the interface methods of the ''ISDFindProvider'' have to be implemented by a class. Typically, this is implemented in the loader class. Add the ISDFindProvider to the list of implemented interfaces, implement the methods ''find()'' and ''cancel()'' and set the provider in the ''setViewer()'' method as well as remove the provider in the ''dispose()'' method of the loader class. Please note that the ''ISDFindProvider'' extends the interface ''ISDGraphNodeSupporter'' which methods (''isNodeSupported()'' and ''getNodeName()'') have to be implemented, too. The following shows an example implementation. Please note that only search for lifelines and SynchMessage are supported. The find itself will always find only the first occurrence the pattern to match.
2337 public class SampleLoader implements IUml2SDLoader, ISDPagingProvider, ISDFindProvider {
2341 public void dispose() {
2342 if (fSdView != null) {
2343 fSdView.resetProviders();
2348 public void setViewer(SDView arg0) {
2350 fSdView.setSDPagingProvider(this);
2351 fSdView.setSDFindProvider(this);
2356 public boolean isNodeSupported(int nodeType) {
2358 case ISDGraphNodeSupporter.LIFELINE:
2359 case ISDGraphNodeSupporter.SYNCMESSAGE:
2369 public String getNodeName(int nodeType, String loaderClassName) {
2371 case ISDGraphNodeSupporter.LIFELINE:
2373 case ISDGraphNodeSupporter.SYNCMESSAGE:
2374 return "Sync Message";
2380 public boolean find(Criteria criteria) {
2381 Frame frame = fSdView.getFrame();
2382 if (criteria.isLifeLineSelected()) {
2383 for (int i = 0; i < frame.lifeLinesCount(); i++) {
2384 if (criteria.matches(frame.getLifeline(i).getName())) {
2385 fSdView.getSDWidget().moveTo(frame.getLifeline(i));
2390 if (criteria.isSyncMessageSelected()) {
2391 for (int i = 0; i < frame.syncMessageCount(); i++) {
2392 if (criteria.matches(frame.getSyncMessage(i).getName())) {
2393 fSdView.getSDWidget().moveTo(frame.getSyncMessage(i));
2402 public void cancel() {
2403 // reset find parameters
2409 When running the example application, the find action will be shown in the coolbar and the coolbar menu. <br>
2410 [[Image:images/FindProviderAdded.png]]
2412 To find a sequence diagram node press on the find button of the coolbar (see above). A new dialog box will open. Enter a regular expression in the ''Matching String'' text box, select the node types (e.g. Sync Message) and press '''Find'''. If found the corresponding node will be selected. If not found the dialog box will indicate not found. <br>
2413 [[Image:images/FindDialog.png]]<br>
2415 Note that the find dialog will be opened by typing the key shortcut CRTL+F.
2417 ==== Using the Filter Provider Interface ====
2419 For filtering of sequence diagram elements two interfaces exist. One basic for filtering and one for extended filtering. The basic filtering comes with two dialog for entering filter criteria as regular expressions and one for selecting the filter to be used. Multiple filters can be active at a time. Filter criteria are persisted in the Eclipse workspace.
2421 To use the basic filter provider, first the interface method of the ''ISDFilterProvider'' has to be implemented by a class. Typically, this is implemented in the loader class. Add the ''ISDFilterProvider'' to the list of implemented interfaces, implement the method ''filter()''and set the provider in the ''setViewer()'' method as well as remove the provider in the ''dispose()'' method of the loader class. Please note that the ''ISDFindProvider'' extends the interface ''ISDGraphNodeSupporter'' which methods (''isNodeSupported()'' and ''getNodeName()'') have to be implemented, too. <br>
2422 Note that no example implementation of ''filter()'' is provided.
2426 public class SampleLoader implements IUml2SDLoader, ISDPagingProvider, ISDFindProvider, ISDFilterProvider {
2430 public void dispose() {
2431 if (fSdView != null) {
2432 fSdView.resetProviders();
2437 public void setViewer(SDView arg0) {
2439 fSdView.setSDPagingProvider(this);
2440 fSdView.setSDFindProvider(this);
2441 fSdView.setSDFilterProvider(this);
2446 public boolean filter(List<?> list) {
2453 When running the example application, the filter action will be shown in the coolbar menu. <br>
2454 [[Image:images/HidePatternsMenuItem.png]]
2456 To filter select the '''Hide Patterns...''' of the coolbar menu. A new dialog box will open. <br>
2457 [[Image:images/DialogHidePatterns.png]]
2459 To Add a new filter press '''Add...'''. A new dialog box will open. Enter a regular expression in the ''Matching String'' text box, select the node types (e.g. Sync Message) and press '''Create''''. <br>
2460 [[Image:images/DialogHidePatterns.png]] <br>
2462 Now back at the Hide Pattern dialog. Select one or more filter and select '''OK'''.
2464 To use the extended filter provider, the interface ''ISDExtendedFilterProvider'' has to be implemented. It will provide a ''org.eclipse.jface.action.Action'' class containing the actual filter handling and filter algorithm.
2466 ==== Using the Extended Action Bar Provider Interface ====
2468 The extended action bar provider can be used to add customized actions to the Sequence Diagram View.
2469 To use the extended action bar provider, first the interface method of the interface ''ISDExtendedActionBarProvider'' has to be implemented by a class. Typically, this is implemented in the loader class. Add the ''ISDExtendedActionBarProvider'' to the list of implemented interfaces, implement the method ''supplementCoolbarContent()'' and set the provider in the ''setViewer()'' method as well as remove the provider in the ''dispose()'' method of the loader class. <br>
2472 public class SampleLoader implements IUml2SDLoader, ISDPagingProvider, ISDFindProvider, ISDFilterProvider, ISDExtendedActionBarProvider {
2476 public void dispose() {
2477 if (fSdView != null) {
2478 fSdView.resetProviders();
2483 public void setViewer(SDView arg0) {
2485 fSdView.setSDPagingProvider(this);
2486 fSdView.setSDFindProvider(this);
2487 fSdView.setSDFilterProvider(this);
2488 fSdView.setSDExtendedActionBarProvider(this);
2493 public void supplementCoolbarContent(IActionBars iactionbars) {
2494 Action action = new Action("Refresh") {
2497 System.out.println("Refreshing...");
2500 iactionbars.getMenuManager().add(action);
2501 iactionbars.getToolBarManager().add(action);
2507 When running the example application, all new actions will be added to the coolbar and coolbar menu according to the implementation of ''supplementCoolbarContent()''<br>.
2508 For the example above the coolbar and coolbar menu will look as follows.
2510 [[Image:images/SupplCoolbar.png]]
2512 ==== Using the Properties Provider Interface====
2514 This interface can be used to provide property information. A property provider which returns an ''IPropertyPageSheet'' (see ''org.eclipse.ui.views'') has to be implemented and set in the Sequence Diagram View. <br>
2516 To use the property provider, first the interface method of the ''ISDPropertiesProvider'' has to be implemented by a class. Typically, this is implemented in the loader class. Add the ''ISDPropertiesProvider'' to the list of implemented interfaces, implement the method ''getPropertySheetEntry()'' and set the provider in the ''setViewer()'' method as well as remove the provider in the ''dispose()'' method of the loader class. Please note that no example is provided here.
2518 Please refer to the following Eclipse articles for more information about properties and tabed properties.
2519 *[http://www.eclipse.org/articles/Article-Properties-View/properties-view.html | Take control of your properties]
2520 *[http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html | The Eclipse Tabbed Properties View]
2522 ==== Using the Collapse Provider Interface ====
2524 This interface can be used to define a provider which responsibility is to collapse two selected lifelines. This can be used to hide a pair of lifelines.
2526 To use the collapse provider, first the interface method of the ''ISDCollapseProvider'' has to be implemented by a class. Typically, this is implemented in the loader class. Add the ISDCollapseProvider to the list of implemented interfaces, implement the method ''collapseTwoLifelines()'' and set the provider in the ''setViewer()'' method as well as remove the provider in the ''dispose()'' method of the loader class. Please note that no example is provided here.
2528 ==== Using the Selection Provider Service ====
2530 The Sequence Diagram View comes with a build in selection provider service. To this service listeners can be added. To use the selection provider service, the interface ''ISelectionListener'' of plug-in ''org.eclipse.ui'' has to implemented. Typically this is implemented in loader class. Firstly, add the ''ISelectionListener'' interface to the list of implemented interfaces, implement the method ''selectionChanged()'' and set the listener in method ''setViewer()'' as well as remove the listener in the ''dispose()'' method of the loader class.
2533 public class SampleLoader implements IUml2SDLoader, ISDPagingProvider, ISDFindProvider, ISDFilterProvider, ISDExtendedActionBarProvider, ISelectionListener {
2537 public void dispose() {
2538 if (fSdView != null) {
2539 PlatformUI.getWorkbench().getActiveWorkbenchWindow().getSelectionService().removePostSelectionListener(this);
2540 fSdView.resetProviders();
2545 public String getTitleString() {
2546 return "Sample Diagram";
2550 public void setViewer(SDView arg0) {
2552 PlatformUI.getWorkbench().getActiveWorkbenchWindow().getSelectionService().addPostSelectionListener(this);
2553 fSdView.setSDPagingProvider(this);
2554 fSdView.setSDFindProvider(this);
2555 fSdView.setSDFilterProvider(this);
2556 fSdView.setSDExtendedActionBarProvider(this);
2562 public void selectionChanged(IWorkbenchPart part, ISelection selection) {
2563 ISelection sel = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getSelectionService().getSelection();
2564 if (sel != null && (sel instanceof StructuredSelection)) {
2565 StructuredSelection stSel = (StructuredSelection) sel;
2566 if (stSel.getFirstElement() instanceof BaseMessage) {
2567 BaseMessage syncMsg = ((BaseMessage) stSel.getFirstElement());
2568 System.out.println("Message '" + syncMsg.getName() + "' selected.");
2577 === Printing a Sequence Diagram ===
2579 To print a the whole sequence diagram or only parts of it, select the Sequence Diagram View and select '''File -> Print...''' or type the key combination ''CTRL+P''. A new print dialog will open. <br>
2581 [[Image:images/PrintDialog.png]] <br>
2583 Fill in all the relevant information, select '''Printer...''' to choose the printer and the press '''OK'''.
2585 === Using one Sequence Diagram View with Multiple Loaders ===
2587 A Sequence Diagram View definition can be used with multiple sequence diagram loaders. However, the active loader to be used when opening the view has to be set. For this define an Eclipse action or command and assign the current loader to the view. Here is a code snippet for that:
2590 public class OpenSDView extends AbstractHandler {
2592 public Object execute(ExecutionEvent event) throws ExecutionException {
2594 IWorkbenchPage persp = TmfUiPlugin.getDefault().getWorkbench().getActiveWorkbenchWindow().getActivePage();
2595 SDView view = (SDView) persp.showView("org.eclipse.linuxtools.ust.examples.ui.componentinteraction");
2596 LoadersManager.getLoadersManager().createLoader("org.eclipse.linuxtools.tmf.ui.views.uml2sd.impl.TmfUml2SDSyncLoader", view);
2597 } catch (PartInitException e) {
2598 throw new ExecutionException("PartInitException caught: ", e);
2605 === Downloading the Tutorial ===
2607 Use the following link to download the source code of the tutorial [http://wiki.eclipse.org/images/e/e6/SamplePlugin.zip Plug-in of Tutorial].
2609 == Integration of Tracing and Monitoring Framework with Sequence Diagram Framework ==
2611 In the previous sections the Sequence Diagram Framework has been described and a tutorial was provided. In the following sections the integration of the Sequence Diagram Framework with other features of TMF will be described. Together it is a powerful framework to analyze and visualize content of traces. The integration is explained using the reference implementation of a UML2 sequence diagram loader which part of the TMF UI delivery. The reference implementation can be used as is, can be sub-classed or simply be an example for other sequence diagram loaders to be implemented.
2613 === Reference Implementation ===
2615 A Sequence Diagram View Extension is defined in the plug-in TMF UI as well as a uml2SDLoader Extension with the reference loader.
2617 [[Image:images/ReferenceExtensions.png]]
2619 === Used Sequence Diagram Features ===
2621 Besides the default features of the Sequence Diagram Framework, the reference implementation uses the following additional features:
2627 ==== Advanced paging ====
2629 The reference loader implements the interface ''ISDAdvancedPagingProvider'' interface. Please refer to section [[#Using the Paging Provider Interface | Using the Paging Provider Interface]] for more details about the advanced paging feature.
2631 ==== Basic finding ====
2633 The reference loader implements the interface ''ISDFindProvider'' interface. The user can search for ''Lifelines'' and ''Interactions''. The find is done across pages. If the expression to match is not on the current page a new thread is started to search on other pages. If expression is found the corresponding page is shown as well as the searched item is displayed. If not found then a message is displayed in the ''Progress View'' of Eclipse. Please refer to section [[#Using the Find Provider Interface | Using the Find Provider Interface]] for more details about the basic find feature.
2635 ==== Basic filtering ====
2637 The reference loader implements the interface ''ISDFilterProvider'' interface. The user can filter on ''Lifelines'' and ''Interactions''. Please refer to section [[#Using the Filter Provider Interface | Using the Filter Provider Interface]] for more details about the basic filter feature.
2639 ==== Selection Service ====
2641 The reference loader implements the interface ''ISelectionListener'' interface. When an interaction is selected a ''TmfTimeSynchSignal'' is broadcast (see [[#TMF Signal Framework | TMF Signal Framework]]). Please also refer to section [[#Using the Selection Provider Service | Using the Selection Provider Service]] for more details about the selection service and .
2643 === Used TMF Features ===
2645 The reference implementation uses the following features of TMF:
2646 *TMF Experiment and Trace for accessing traces
2647 *Event Request Framework to request TMF events from the experiment and respective traces
2648 *Signal Framework for broadcasting and receiving TMF signals for synchronization purposes
2650 ==== TMF Experiment and Trace for accessing traces ====
2652 The reference loader uses TMF Experiments to access traces and to request data from the traces.
2654 ==== TMF Event Request Framework ====
2656 The reference loader use the TMF Event Request Framework to request events from the experiment and its traces.
2658 When opening a traces (which is triggered by signal ''TmfExperimentSelected'') or when opening the Sequence Diagram View after a trace had been opened previously, a TMF background request is initiated to index the trace and to fill in the first page of the sequence diagram. The purpose of the indexing is to store time ranges for pages with 10000 messages per page. This allows quickly to move to certain pages in a trace without having to re-parse from the beginning. The request is called indexing request.
2660 When switching pages, the a TMF foreground event request is initiated to retrieve the corresponding events from the experiment. It uses the time range stored in the index for the respective page.
2662 A third type of event request is issued for finding specific data across pages.
2664 ==== TMF Signal Framework ====
2666 The reference loader extends the class ''TmfComponent''. By doing that the loader is registered as a TMF signal handler for sending and receiving TMF signals. The loader implements signal handlers for the following TMF signals:
2667 *''TmfTraceSelectedSignal''
2668 This signal indicates that a trace or experiment was selected. When receiving this signal the indexing request is initiated and the first page is displayed after receiving the relevant information.
2669 *''TmfTraceClosedSignal''
2670 This signal indicates that a trace or experiment was closed. When receiving this signal the loader resets its data and a blank page is loaded in the Sequence Diagram View.
2671 *''TmfTimeSynchSignal''
2672 This signal is used to indicate that a new time or time range has been selected. It contains a begin and end time. If a single time is selected then the begin and end time are the same. When receiving this signal the corresponding message matching the begin time is selected in the Sequence Diagram View. If necessary, the page is changed.
2673 *''TmfRangeSynchSignal''
2674 This signal indicates that a new time range is in focus. When receiving this signal the loader loads the page which corresponds to the start time of the time range signal. The message with the start time will be in focus.
2676 Besides acting on receiving signals, the reference loader is also sending signals. A ''TmfTimeSynchSignal'' is broadcasted with the timestamp of the message which was selected in the Sequence Diagram View. ''TmfRangeSynchSignal'' is sent when a page is changed in the Sequence Diagram View. The start timestamp of the time range sent is the timestamp of the first message. The end timestamp sent is the timestamp of the first message plus the current time range window. The current time range window is the time window that was indicated in the last received ''TmfRangeSynchSignal''.
2678 === Supported Traces ===
2680 The reference implementation is able to analyze traces from a single component that traces the interaction with other components. For example, a server node could have trace information about its interaction with client nodes. The server node could be traced and then analyzed using TMF and the Sequence Diagram Framework of TMF could used to visualize the interactions with the client nodes.<br>
2682 Note that combined traces of multiple components, that contain the trace information about the same interactions are not supported in the reference implementation!
2684 === Trace Format ===
2686 The reference implementation in class ''TmfUml2SDSyncLoader'' in package ''org.eclipse.linuxtools.tmf.ui.views.uml2sd.impl'' analyzes events from type ''ITmfEvent'' and creates events type ''ITmfSyncSequenceDiagramEvent'' if the ''ITmfEvent'' contains all relevant information information. The parsing algorithm looks like as follows:
2690 * @param tmfEvent Event to parse for sequence diagram event details
2691 * @return sequence diagram event if details are available else null
2693 protected ITmfSyncSequenceDiagramEvent getSequenceDiagramEvent(ITmfEvent tmfEvent){
2694 //type = .*RECEIVE.* or .*SEND.*
2695 //content = sender:<sender name>:receiver:<receiver name>,signal:<signal name>
2696 String eventType = tmfEvent.getType().toString();
2697 if (eventType.contains(Messages.TmfUml2SDSyncLoader_EventTypeSend) || eventType.contains(Messages.TmfUml2SDSyncLoader_EventTypeReceive)) {
2698 Object sender = tmfEvent.getContent().getField(Messages.TmfUml2SDSyncLoader_FieldSender);
2699 Object receiver = tmfEvent.getContent().getField(Messages.TmfUml2SDSyncLoader_FieldReceiver);
2700 Object name = tmfEvent.getContent().getField(Messages.TmfUml2SDSyncLoader_FieldSignal);
2701 if ((sender instanceof ITmfEventField) && (receiver instanceof ITmfEventField) && (name instanceof ITmfEventField)) {
2702 ITmfSyncSequenceDiagramEvent sdEvent = new TmfSyncSequenceDiagramEvent(tmfEvent,
2703 ((ITmfEventField) sender).getValue().toString(),
2704 ((ITmfEventField) receiver).getValue().toString(),
2705 ((ITmfEventField) name).getValue().toString());
2714 The analysis looks for event type Strings containing ''SEND'' and ''RECEIVE''. If event type matches these key words, the analyzer will look for strings ''sender'', ''receiver'' and ''signal'' in the event fields of type ''ITmfEventField''. If all the data is found a sequence diagram event can be created using this information. Note that Sync Messages are assumed, which means start and end time are the same.
2716 === How to use the Reference Implementation ===
2718 An example CTF (Common Trace Format) trace is provided that contains trace events with sequence diagram information. To download the reference trace, use the following link: [https://wiki.eclipse.org/images/3/35/ReferenceTrace.zip Reference Trace].
2720 Run an Eclipse application with TMF 3.0 or later installed. To open the Reference Sequence Diagram View, select '''Windows -> Show View -> Other... -> TMF -> Sequence Diagram''' <br>
2721 [[Image:images/ShowTmfSDView.png]]<br>
2723 A blank Sequence Diagram View will open.
2725 Then import the reference trace to the '''Project Explorer''' using the '''Import Trace Package...''' menu option.<br>
2726 [[Image:images/ImportTracePackage.png]]
2728 Next, open the trace by double-clicking on the trace element in the '''Project Explorer'''. The trace will be opened and the Sequence Diagram view will be filled.
2729 [[Image:images/ReferenceSeqDiagram.png]]<br>
2731 Now the reference implementation can be explored. To demonstrate the view features try the following things:
2732 *Select a message in the Sequence diagram. As result the corresponding event will be selected in the Events View.
2733 *Select an event in the Events View. As result the corresponding message in the Sequence Diagram View will be selected. If necessary, the page will be changed.
2734 *In the Events View, press key ''End''. As result, the Sequence Diagram view will jump to the last page.
2735 *In the Events View, press key ''Home''. As result, the Sequence Diagram view will jump to the first page.
2736 *In the Sequence Diagram View select the find button. Enter the expression '''REGISTER.*''', select '''Search for Interaction''' and press '''Find'''. As result the corresponding message will be selected in the Sequence Diagram and the corresponding event in the Events View will be selected. Select again '''Find''' the next occurrence of will be selected. Since the second occurrence is on a different page than the first, the corresponding page will be loaded.
2737 * In the Sequence Diagram View, select menu item '''Hide Patterns...'''. Add the filter '''BALL.*''' for '''Interaction''' only and select '''OK'''. As result all messages with name ''BALL_REQUEST'' and ''BALL_REPLY'' will be hidden. To remove the filter, select menu item '''Hide Patterns...''', deselect the corresponding filter and press '''OK'''. All the messages will be shown again.<br>
2739 === Extending the Reference Loader ===
2741 In some case it might be necessary to change the implementation of the analysis of each ''TmfEvent'' for the generation of ''Sequence Diagram Events''. For that just extend the class ''TmfUml2SDSyncLoader'' and overwrite the method ''protected ITmfSyncSequenceDiagramEvent getSequnceDiagramEvent(TmfEvent tmfEvent)'' with your own implementation.
2746 CTF is a format used to store traces. It is self defining, binary and made to be easy to write to.
2747 Before going further, the full specification of the CTF file format can be found at http://www.efficios.com/ .
2749 For the purpose of the reader some basic description will be given. A CTF trace typically is made of several files all in the same folder.
2751 These files can be split into two types :
2756 The metadata is either raw text or packetized text. It is tsdl encoded. it contains a description of the type of data in the event streams. It can grow over time if new events are added to a trace but it will never overwrite what is already there.
2758 === Event Streams ===
2759 The event streams are a file per stream per cpu. These streams are binary and packet based. The streams store events and event information (ie lost events) The event data is stored in headers and field payloads.
2761 So if you have two streams (channels) "channel1" and "channel2" and 4 cores, you will have the following files in your trace directory: "channel1_0" , "channel1_1" , "channel1_2" , "channel1_3" , "channel2_0" , "channel2_1" , "channel2_2" & "channel2_3"
2763 == Reading a trace ==
2764 In order to read a CTF trace, two steps must be done.
2765 * The metadata must be read to know how to read the events.
2766 * the events must be read.
2768 The metadata is a written in a subset of the C language called TSDL. To read it, first it is depacketized (if it is not in plain text) then the raw text is parsed by an antlr grammer. The parsing is done in two phases. There is a lexer (CTFLexer.g) which separated the metatdata text into tokens. The tokens are then pattern matched using the parser (CTFParser.g) to form an AST. This AST is walked through using "IOStructGen.java" to populate streams and traces in trace parent object.
2770 When the metadata is loaded and read, the trace object will be populated with 3 items:
2771 * the event definitions available per stream: a definition is a description of the datatype.
2772 * the event declarations available per stream: this will save declaration creation on a per event basis. They will all be created in advance, just not populated.
2773 * the beginning of a packet index.
2775 Now all the trace readers for the event streams have everything they need to read a trace. They will each point to one file, and read the file from packet to packet. Everytime the trace reader changes packet, the index is updated with the new packet's information. The readers are in a priority queue and sorted by timestamp. This ensures that the events are read in a sequential order. They are also sorted by file name so that in the eventuality that two events occur at the same time, they stay in the same order.
2777 == Seeking in a trace ==
2778 The reason for maintaining an index is to speed up seeks. In the case that a user wishes to seek to a certain timestamp, they just have to find the index entry that contains the timestamp, and go there to iterate in that packet until the proper event is found. this will reduce the searches time by an order of 8000 for a 256k paket size (kernel default).
2780 == Interfacing to TMF ==
2781 The trace can be read easily now but the data is still awkward to extract.
2784 A location in a given trace, it is currently the timestamp of a trace and the index of the event. The index shows for a given timestamp if it is the first second or nth element.
2787 The CtfTmfTrace is a wrapper for the standard CTF trace that allows it to perform the following actions:
2788 * '''initTrace()''' create a trace
2789 * '''validateTrace()''' is the trace a CTF trace?
2790 * '''getLocationRatio()''' how far in the trace is my location?
2791 * '''seekEvent()''' sets the cursor to a certain point in a trace.
2792 * '''readNextEvent()''' reads the next event and then advances the cursor
2793 * '''getTraceProperties()''' gets the 'env' structures of the metadata
2796 The CtfIterator is a wrapper to the CTF file reader. It behaves like an iterator on a trace. However, it contains a file pointer and thus cannot be duplicated too often or the system will run out of file handles. To alleviate the situation, a pool of iterators is created at the very beginning and stored in the CtfTmfTrace. They can be retried by calling the GetIterator() method.
2798 === CtfIteratorManager ===
2799 Since each CtfIterator will have a file reader, the OS will run out of handles if too many iterators are spawned. The solution is to use the iterator manager. This will allow the user to get an iterator. If there is a context at the requested position, the manager will return that one, if not, a context will be selected at random and set to the correct location. Using random replacement minimizes contention as it will settle quickly at a new balance point.
2801 === CtfTmfContext ===
2802 The CtfTmfContext implements the ITmfContext type. It is the CTF equivalent of TmfContext. It has a CtfLocation and points to an iterator in the CtfTmfTrace iterator pool as well as the parent trace. it is made to be cloned easily and not affect system resources much. Contexts behave much like C file pointers (FILE*) but they can be copied until one runs out of RAM.
2804 === CtfTmfTimestamp ===
2805 The CtfTmfTimestamp take a CTF time (normally a long int) and outputs the time formats it as a TmfTimestamp, allowing it to be compared to other timestamps. The time is stored with the UTC offset already applied. It also features a simple toString() function that allows it to output the time in more Human readable ways: "yyyy/mm/dd/hh:mm:ss.nnnnnnnnn ns" for example. An additional feature is the getDelta() function that allows two timestamps to be substracted, showing the time difference between A and B.
2808 The CtfTmfEvent is an ITmfEvent that is used to wrap event declarations and event definitions from the CTF side into easier to read and parse chunks of information. It is a final class with final fields made to be newed very often without incurring performance costs. Most of the information is already available. It should be noted that one type of event can appear called "lost event" these are synthetic events that do not exist in the trace. They will not appear in other trace readers such as babeltrace.
2811 There are other helper files that format given events for views, they are simpler and the architecture does not depend on them.
2814 For the moment live trace reading is not supported, there are no sources of traces to test on.
2816 = Event matching and trace synchronization =
2818 Event matching consists in taking an event from a trace and linking it to another event in a possibly different trace. The example that comes to mind is matching network packets sent from one traced machine to another traced machine. These matches can be used to synchronize traces.
2820 Trace synchronization consists in taking traces, taken on different machines, with a different time reference, and finding the formula to transform the timestamps of some of the traces, so that they all have the same time reference.
2822 == Event matching interfaces ==
2824 Here's a description of the major parts involved in event matching. These classes are all in the ''org.eclipse.linuxtools.tmf.core.event.matching'' package:
2826 * '''ITmfEventMatching''': Controls the event matching process
2827 * '''ITmfMatchEventDefinition''': Describes how events are matched
2828 * '''IMatchProcessingUnit''': Processes the matched events
2830 == Implementation details and how to extend it ==
2832 === ITmfEventMatching interface and derived classes ===
2834 This interface and its default abstract implementation '''TmfEventMatching''' control the event matching itself. Their only public method is ''matchEvents''. The class needs to manage how to setup the traces, and any initialization or finalization procedures.
2836 The abstract class generates an event request for each trace from which events are matched and waits for the request to complete before calling the one from another trace. The ''handleData'' method from the request calls the ''matchEvent'' method that needs to be implemented in children classes.
2838 Class '''TmfNetworkEventMatching''' is a concrete implementation of this interface. It applies to all use cases where a ''in'' event can be matched with a ''out' event (''in'' and ''out'' can be the same event, with different data). It creates a '''TmfEventDependency''' between the source and destination events. The dependency is added to the processing unit.
2840 To match events requiring other mechanisms (for instance, a series of events can be matched with another series of events), one would need to implement another class either extending '''TmfEventMatching''' or implementing '''ITmfEventMatching'''. It would most probably also require a new '''ITmfMatchEventDefinition''' implementation.
2842 === ITmfMatchEventDefinition interface and its derived classes ===
2844 These are the classes that describe how to actually match specific events together.
2846 The '''canMatchTrace''' method will tell if a definition is compatible with a given trace.
2848 The '''getUniqueField''' method will return a list of field values that uniquely identify this event and can be used to find a previous event to match with.
2850 Typically, there would be a match definition abstract class/interface per event matching type.
2852 The interface '''ITmfNetworkMatchDefinition''' adds the ''getDirection'' method to indicate whether this event is a ''in'' or ''out'' event to be matched with one from the opposite direction.
2854 As examples, two concrete network match definitions have been implemented in the ''org.eclipse.linuxtools.lttng2.kernel.core.event.matching'' package for two compatible methods of matching TCP packets (See the LTTng User Guide on ''trace synchronization'' for information on those matching methods). Each one tells which events need to be present in the metadata of a CTF trace for this matching method to be applicable. It also returns the field values from each event that will uniquely match 2 events together.
2856 === IMatchProcessingUnit interface and derived classes ===
2858 While matching events is an exercice in itself, it's what to do with the match that really makes this functionality interesting. This is the job of the '''IMatchProcessingUnit''' interface.
2860 '''TmfEventMatches''' provides a default implementation that only stores the matches to count them. When a new match is obtained, the ''addMatch'' is called with the match and the processing unit can do whatever needs to be done with it.
2862 A match processing unit can be an analysis in itself. For example, trace synchronization is done through such a processing unit. One just needs to set the processing unit in the TmfEventMatching constructor.
2866 === Using network packets matching in an analysis ===
2868 This example shows how one can create a processing unit inline to create a link between two events. In this example, the code already uses an event request, so there is no need here to call the ''matchEvents'' method, that will only create another request.
2871 class MyAnalysis extends TmfAbstractAnalysisModule {
2873 private TmfNetworkEventMatching tcpMatching;
2877 protected void executeAnalysis() {
2879 IMatchProcessingUnit matchProcessing = new IMatchProcessingUnit() {
2881 public void matchingEnded() {
2885 public void init(ITmfTrace[] fTraces) {
2889 public int countMatches() {
2894 public void addMatch(TmfEventDependency match) {
2895 log.debug("we got a tcp match! " + match.getSourceEvent().getContent() + " " + match.getDestinationEvent().getContent());
2896 TmfEvent source = match.getSourceEvent();
2897 TmfEvent destination = match.getDestinationEvent();
2898 /* Create a link between the two events */
2902 ITmfTrace[] traces = { getTrace() };
2903 tcpMatching = new TmfNetworkEventMatching(traces, matchProcessing);
2904 tcpMatching.initMatching();
2906 MyEventRequest request = new MyEventRequest(this, i);
2907 getTrace().sendRequest(request);
2910 public void analyzeEvent(TmfEvent event) {
2912 tcpMatching.matchEvent(event, 0);
2920 class MyEventRequest extends TmfEventRequest {
2922 private final MyAnalysis analysis;
2924 MyEventRequest(MyAnalysis analysis, int traceno) {
2925 super(CtfTmfEvent.class,
2926 TmfTimeRange.ETERNITY,
2928 TmfDataRequest.ALL_DATA,
2929 ITmfDataRequest.ExecutionType.FOREGROUND);
2930 this.analysis = analysis;
2934 public void handleData(final ITmfEvent event) {
2935 super.handleData(event);
2936 if (event != null) {
2937 analysis.analyzeEvent(event);
2943 === Match network events from UST traces ===
2945 Suppose a client-server application is instrumented using LTTng-UST. Traces are collected on the server and some clients on different machines. The traces can be synchronized using network event matching.
2947 The following metadata describes the events:
2951 name = "myapp:send";
2956 integer { size = 32; align = 8; signed = 1; encoding = none; base = 10; } _sendto;
2957 integer { size = 64; align = 8; signed = 1; encoding = none; base = 10; } _messageid;
2958 integer { size = 64; align = 8; signed = 1; encoding = none; base = 10; } _data;
2963 name = "myapp:receive";
2968 integer { size = 32; align = 8; signed = 1; encoding = none; base = 10; } _from;
2969 integer { size = 64; align = 8; signed = 1; encoding = none; base = 10; } _messageid;
2970 integer { size = 64; align = 8; signed = 1; encoding = none; base = 10; } _data;
2975 One would need to write an event match definition for those 2 events as follows:
2978 public class MyAppUstEventMatching implements ITmfNetworkMatchDefinition {
2981 public Direction getDirection(ITmfEvent event) {
2982 String evname = event.getType().getName();
2983 if (evname.equals("myapp:receive")) {
2984 return Direction.IN;
2985 } else if (evname.equals("myapp:send")) {
2986 return Direction.OUT;
2992 public List<Object> getUniqueField(ITmfEvent event) {
2993 List<Object> keys = new ArrayList<Object>();
2995 if (evname.equals("myapp:receive")) {
2996 keys.add(event.getContent().getField("from").getValue());
2997 keys.add(event.getContent().getField("messageid").getValue());
2999 keys.add(event.getContent().getField("sendto").getValue());
3000 keys.add(event.getContent().getField("messageid").getValue());
3007 public boolean canMatchTrace(ITmfTrace trace) {
3008 if (!(trace instanceof CtfTmfTrace)) {
3011 CtfTmfTrace ktrace = (CtfTmfTrace) trace;
3012 String[] events = { "myapp:receive", "myapp:send" };
3013 return ktrace.hasAtLeastOneOfEvents(events);
3017 public MatchingType[] getApplicableMatchingTypes() {
3018 MatchingType[] types = { MatchingType.NETWORK };
3025 Somewhere in code that will be executed at the start of the plugin (like in the Activator), the following code will have to be run:
3028 TmfEventMatching.registerMatchObject(new MyAppUstEventMatching());
3031 Now, only adding the traces in an experiment and clicking the '''Synchronize traces''' menu element would synchronize the traces using the new definition for event matching.
3033 == Trace synchronization ==
3035 Trace synchronization classes and interfaces are located in the ''org.eclipse.linuxtools.tmf.core.synchronization'' package.
3037 === Synchronization algorithm ===
3039 Synchronization algorithms are used to synchronize traces from events matched between traces. After synchronization, traces taken on different machines with different time references see their timestamps modified such that they all use the same time reference (typically, the time of at least one of the traces). With traces from different machines, it is impossible to have perfect synchronization, so the result is a best approximation that takes network latency into account.
3041 The abstract class '''SynchronizationAlgorithm''' is a processing unit for matches. New synchronization algorithms must extend this one, it already contains the functions to get the timestamp transforms for different traces.
3043 The ''fully incremental convex hull'' synchronization algorithm is the default synchronization algorithm.
3045 While the synchronization system provisions for more synchronization algorithms, there is not yet a way to select one, the experiment's trace synchronization uses the default algorithm. To test a new synchronization algorithm, the synchronization should be called directly like this:
3048 SynchronizationAlgorithm syncAlgo = new MyNewSynchronizationAlgorithm();
3049 syncAlgo = SynchronizationManager.synchronizeTraces(syncFile, traces, syncAlgo, true);
3052 === Timestamp transforms ===
3054 Timestamp transforms are the formulae used to transform the timestamps from a trace into the reference time. The '''ITmfTimestampTransform''' is the interface to implement to add a new transform.
3056 The following classes implement this interface:
3058 * '''TmfTimestampTransform''': default transform. It cannot be instantiated, it has a single static object TmfTimestampTransform.IDENTITY, which returns the original timestamp.
3059 * '''TmfTimestampTransformLinear''': transforms the timestamp using a linear formula: ''f(t) = at + b'', where ''a'' and ''b'' are computed by the synchronization algorithm.
3061 One could extend the interface for other timestamp transforms, for instance to have a transform where the formula would change over the course of the trace.
3065 Here's a list of features not yet implemented that would enhance trace synchronization and event matching:
3067 * Ability to select a synchronization algorithm
3068 * Implement a better way to select the reference trace instead of arbitrarily taking the first in alphabetical order (for instance, the minimum spanning tree algorithm by Masoume Jabbarifar (article on the subject not published yet))
3069 * Ability to join traces from the same host so that even if one of the traces is not synchronized with the reference trace, it will take the same timestamp transform as the one on the same machine.
3070 * Instead of having the timestamp transforms per trace, have the timestamp transform as part of an experiment context, so that the trace's specific analysis, like the state system, are in the original trace, but are transformed only when needed for an experiment analysis.
3071 * Add more views to display the synchronization information (only textual statistics are available for now)
3073 = Analysis Framework =
3075 Analysis modules are useful to tell the user exactly what can be done with a trace. The analysis framework provides an easy way to access and execute the modules and open the various outputs available.
3077 Analyses can have parameters they can use in their code. They also have outputs registered to them to display the results from their execution.
3079 == Creating a new module ==
3081 All analysis modules must implement the '''IAnalysisModule''' interface from the o.e.l.tmf.core project. An abstract class, '''TmfAbstractAnalysisModule''', provides a good base implementation. It is strongly suggested to use it as a superclass of any new analysis.
3085 This example shows how to add a simple analysis module for an LTTng kernel trace with two parameters.
3088 public class MyLttngKernelAnalysis extends TmfAbstractAnalysisModule {
3090 public static final String PARAM1 = "myparam";
3091 public static final String PARAM2 = "myotherparam";
3094 public boolean canExecute(ITmfTrace trace) {
3095 /* This just makes sure the trace is an Lttng kernel trace, though
3096 usually that should have been done by specifying the trace type
3097 this analysis module applies to */
3098 if (!LttngKernelTrace.class.isAssignableFrom(trace.getClass())) {
3102 /* Does the trace contain the appropriate events? */
3103 String[] events = { "sched_switch", "sched_wakeup" };
3104 return ((LttngKernelTrace) trace).hasAllEvents(events);
3108 protected void canceling() {
3109 /* The job I am running in is being cancelled, let's clean up */
3113 protected boolean executeAnalysis(final IProgressMonitor monitor) {
3115 * I am running in an Eclipse job, and I already know I can execute
3118 * In the end, I will return true if I was successfully completed or
3119 * false if I was either interrupted or something wrong occurred.
3121 Object param1 = getParameter(PARAM1);
3122 int param2 = (Integer) getParameter(PARAM2);
3126 public Object getParameter(String name) {
3127 Object value = super.getParameter(name);
3128 /* Make sure the value of param2 is of the right type. For sake of
3129 simplicity, the full parameter format validation is not presented
3131 if ((value != null) && name.equals(PARAM2) && (value instanceof String)) {
3132 return Integer.parseInt((String) value);
3140 === Available base analysis classes and interfaces ===
3142 The following are available as base classes for analysis modules. They also extend the abstract '''TmfAbstractAnalysisModule'''
3144 * '''TmfStateSystemAnalysisModule''': A base analysis module that builds one state system. A module extending this class only needs to provide a state provider and the type of state system backend to use. All state systems should now use this base class as it also contains all the methods to actually create the state sytem with a given backend.
3146 The following interfaces can optionally be implemented by analysis modules if they use their functionalities. For instance, some utility views, like the State System Explorer, may have access to the module's data through these interfaces.
3148 * '''ITmfAnalysisModuleWithStateSystems''': Modules implementing this have one or more state systems included in them. For example, a module may "hide" 2 state system modules for its internal workings. By implementing this interface, it tells that it has state systems and can return them if required.
3150 === How it works ===
3152 Analyses are managed through the '''TmfAnalysisManager'''. The analysis manager is a singleton in the application and keeps track of all available analysis modules, with the help of '''IAnalysisModuleHelper'''. It can be queried to get the available analysis modules, either all of them or only those for a given tracetype. The helpers contain the non-trace specific information on an analysis module: its id, its name, the tracetypes it applies to, etc.
3154 When a trace is opened, the helpers for the applicable analysis create new instances of the analysis modules. The analysis are then kept in a field of the trace and can be executed automatically or on demand.
3156 The analysis is executed by calling the '''IAnalysisModule#schedule()''' method. This method makes sure the analysis is executed only once and, if it is already running, it won't start again. The analysis itself is run inside an Eclipse job that can be cancelled by the user or the application. The developer must consider the progress monitor that comes as a parameter of the '''executeAnalysis()''' method, to handle the proper cancellation of the processing. The '''IAnalysisModule#waitForCompletion()''' method will block the calling thread until the analysis is completed. The method will return whether the analysis was successfully completed or if it was cancelled.
3158 A running analysis can be cancelled by calling the '''IAnalysisModule#cancel()''' method. This will set the analysis as done, so it cannot start again unless it is explicitly reset. This is done by calling the protected method '''resetAnalysis'''.
3160 == Telling TMF about the analysis module ==
3162 Now that the analysis module class exists, it is time to hook it to the rest of TMF so that it appears under the traces in the project explorer. The way to do so is to add an extension of type ''org.eclipse.linuxtools.tmf.core.analysis'' to a plugin, either through the ''Extensions'' tab of the Plug-in Manifest Editor or by editing directly the plugin.xml file.
3164 The following code shows what the resulting plugin.xml file should look like.
3168 point="org.eclipse.linuxtools.tmf.core.analysis">
3170 id="my.lttng.kernel.analysis.id"
3171 name="My LTTng Kernel Analysis"
3172 analysis_module="my.plugin.package.MyLttngKernelAnalysis"
3179 name="myotherparam">
3181 class="org.eclipse.linuxtools.lttng2.kernel.core.trace.LttngKernelTrace">
3187 This defines an analysis module where the ''analysis_module'' attribute corresponds to the module class and must implement IAnalysisModule. This module has 2 parameters: ''myparam'' and ''myotherparam'' which has default value of 3. The ''tracetype'' element tells which tracetypes this analysis applies to. There can be many tracetypes. Also, the ''automatic'' attribute of the module indicates whether this analysis should be run when the trace is opened, or wait for the user's explicit request.
3189 Note that with these extension points, it is possible to use the same module class for more than one analysis (with different ids and names). That is a desirable behavior. For instance, a third party plugin may add a new tracetype different from the one the module is meant for, but on which the analysis can run. Also, different analyses could provide different results with the same module class but with different default values of parameters.
3191 == Attaching outputs and views to the analysis module ==
3193 Analyses will typically produce outputs the user can examine. Outputs can be a text dump, a .dot file, an XML file, a view, etc. All output types must implement the '''IAnalysisOutput''' interface.
3195 An output can be registered to an analysis module at any moment by calling the '''IAnalysisModule#registerOutput()''' method. Analyses themselves may know what outputs are available and may register them in the analysis constructor or after analysis completion.
3197 The various concrete output types are:
3199 * '''TmfAnalysisViewOutput''': It takes a view ID as parameter and, when selected, opens the view.
3201 === Using the extension point to add outputs ===
3203 Analysis outputs can also be hooked to an analysis using the same extension point ''org.eclipse.linuxtools.tmf.core.analysis'' in the plugin.xml file. Outputs can be matched either to a specific analysis identified by an ID, or to all analysis modules extending or implementing a given class or interface.
3205 The following code shows how to add a view output to the analysis defined above directly in the plugin.xml file. This extension does not have to be in the same plugin as the extension defining the analysis. Typically, an analysis module can be defined in a core plugin, along with some outputs that do not require UI elements. Other outputs, like views, who need UI elements, will be defined in a ui plugin.
3209 point="org.eclipse.linuxtools.tmf.core.analysis">
3211 class="org.eclipse.linuxtools.tmf.ui.analysis.TmfAnalysisViewOutput"
3212 id="my.plugin.package.ui.views.myView">
3214 id="my.lttng.kernel.analysis.id">
3218 class="org.eclipse.linuxtools.tmf.ui.analysis.TmfAnalysisViewOutput"
3219 id="my.plugin.package.ui.views.myMoreGenericView">
3220 <analysisModuleClass
3221 class="my.plugin.package.core.MyAnalysisModuleClass">
3222 </analysisModuleClass>
3227 == Providing help for the module ==
3229 For now, the only way to provide a meaningful help message to the user is by overriding the '''IAnalysisModule#getHelpText()''' method and return a string that will be displayed in a message box.
3231 What still needs to be implemented is for a way to add a full user/developer documentation with mediawiki text file for each module and automatically add it to Eclipse Help. Clicking on the Help menu item of an analysis module would open the corresponding page in the help.
3233 == Using analysis parameter providers ==
3235 An analysis may have parameters that can be used during its execution. Default values can be set when describing the analysis module in the plugin.xml file, or they can use the '''IAnalysisParameterProvider''' interface to provide values for parameters. '''TmfAbstractAnalysisParamProvider''' provides an abstract implementation of this interface, that automatically notifies the module of a parameter change.
3237 === Example parameter provider ===
3239 The following example shows how to have a parameter provider listen to a selection in the LTTng kernel Control Flow view and send the thread id to the analysis.
3242 public class MyLttngKernelParameterProvider extends TmfAbstractAnalysisParamProvider {
3244 private ControlFlowEntry fCurrentEntry = null;
3246 private static final String NAME = "My Lttng kernel parameter provider"; //$NON-NLS-1$
3248 private ISelectionListener selListener = new ISelectionListener() {
3250 public void selectionChanged(IWorkbenchPart part, ISelection selection) {
3251 if (selection instanceof IStructuredSelection) {
3252 Object element = ((IStructuredSelection) selection).getFirstElement();
3253 if (element instanceof ControlFlowEntry) {
3254 ControlFlowEntry entry = (ControlFlowEntry) element;
3255 setCurrentThreadEntry(entry);
3264 public CriticalPathParameterProvider() {
3270 public String getName() {
3275 public Object getParameter(String name) {
3276 if (fCurrentEntry == null) {
3279 if (name.equals(MyLttngKernelAnalysis.PARAM1)) {
3280 return fCurrentEntry.getThreadId()
3286 public boolean appliesToTrace(ITmfTrace trace) {
3287 return (trace instanceof LttngKernelTrace);
3290 private void setCurrentThreadEntry(ControlFlowEntry entry) {
3291 if (!entry.equals(fCurrentEntry)) {
3292 fCurrentEntry = entry;
3293 this.notifyParameterChanged(MyLttngKernelAnalysis.PARAM1);
3297 private void registerListener() {
3298 final IWorkbench wb = PlatformUI.getWorkbench();
3300 final IWorkbenchPage activePage = wb.getActiveWorkbenchWindow().getActivePage();
3302 /* Add the listener to the control flow view */
3303 view = activePage.findView(ControlFlowView.ID);
3305 view.getSite().getWorkbenchWindow().getSelectionService().addPostSelectionListener(selListener);
3306 view.getSite().getWorkbenchWindow().getPartService().addPartListener(partListener);
3313 === Register the parameter provider to the analysis ===
3315 To have the parameter provider class register to analysis modules, it must first register through the analysis manager. It can be done in a plugin's activator as follows:
3319 public void start(BundleContext context) throws Exception {
3321 TmfAnalysisManager.registerParameterProvider("my.lttng.kernel.analysis.id", MyLttngKernelParameterProvider.class)
3325 where '''MyLttngKernelParameterProvider''' will be registered to analysis ''"my.lttng.kernel.analysis.id"''. When the analysis module is created, the new module will register automatically to the singleton parameter provider instance. Only one module is registered to a parameter provider at a given time, the one corresponding to the currently selected trace.
3327 == Providing requirements to analyses ==
3329 === Analysis requirement provider API ===
3331 A requirement defines the needs of an analysis. For example, an analysis could need an event named ''"sched_switch"'' in order to be properly executed. The requirements are represented by the class '''TmfAnalysisRequirement'''. Since '''IAnalysisModule''' extends the '''IAnalysisRequirementProvider''' interface, all analysis modules must provide their requirements. If the analysis module extends '''TmfAbstractAnalysisModule''', it has the choice between overriding the requirements getter ('''IAnalysisRequirementProvider#getAnalysisRequirements()''') or not, since the abstract class returns an empty collection by default (no requirements).
3333 === Requirement values ===
3335 When instantiating a requirement, the developer needs to specify a type to which all the values added to the requirement will be linked. In the earlier example, there would be an ''"event"'' or ''"eventName"'' type. The type is represented by a string, like all values added to the requirement object. With an 'event' type requirement, a trace generator like the LTTng Control could automatically enable the required events. This is possible by calling the '''TmfAnalysisRequirementHelper''' class. Another point we have to take into consideration is the priority level of each value added to the requirement object. The enum '''TmfAnalysisRequirement#ValuePriorityLevel''' gives the choice between '''ValuePriorityLevel#MANDATORY''' and '''ValuePriorityLevel#OPTIONAL'''. That way, we can tell if an analysis can run without a value or not. To add values, one must call '''TmfAnalysisRequirement#addValue()'''.
3337 Moreover, information can be added to requirements. That way, the developer can explicitly give help details at the requirement level instead of at the analysis level (which would just be a general help text). To add information to a requirement, the method '''TmfAnalysisRequirement#addInformation()''' must be called. Adding information is not mandatory.
3339 === Example of providing requirements ===
3341 In this example, we will implement a method that initializes a requirement object and return it in the '''IAnalysisRequirementProvider#getAnalysisRequirements()''' getter. The example method will return a set with two requirements. The first one will indicate the events needed by a specific analysis and the last one will tell on what domain type the analysis applies. In the event type requirement, we will indicate that the analysis needs a mandatory event and an optional one.
3345 public Iterable<TmfAnalysisRequirement> getAnalysisRequirements() {
3346 Set<TmfAnalysisRequirement> requirements = new HashSet<>();
3348 /* Create requirements of type 'event' and 'domain' */
3349 TmfAnalysisRequirement eventRequirement = new TmfAnalysisRequirement("event");
3350 TmfAnalysisRequirement domainRequirement = new TmfAnalysisRequirement("domain");
3352 /* Add the values */
3353 domainRequirement.addValue("kernel", TmfAnalysisRequirement.ValuePriorityLevel.MANDATORY);
3354 eventRequirement.addValue("sched_switch", TmfAnalysisRequirement.ValuePriorityLevel.MANDATORY);
3355 eventRequirement.addValue("sched_wakeup", TmfAnalysisRequirement.ValuePriorityLevel.OPTIONAL);
3357 /* An information about the events */
3358 eventRequirement.addInformation("The event sched_wakeup is optional because it's not properly handled by this analysis yet.");
3360 /* Add them to the set */
3361 requirements.add(domainRequirement);
3362 requirements.add(eventRequirement);
3364 return requirements;
3371 Here's a list of features not yet implemented that would improve the analysis module user experience:
3373 * Implement help using the Eclipse Help facility (without forgetting an eventual command line request)
3374 * The abstract class '''TmfAbstractAnalysisModule''' executes an analysis as a job, but nothing compels a developer to do so for an analysis implementing the '''IAnalysisModule''' interface. We should force the execution of the analysis as a job, either from the trace itself or using the TmfAnalysisManager or by some other mean.
3375 * Views and outputs are often registered by the analysis themselves (forcing them often to be in the .ui packages because of the views), because there is no other easy way to do so. We should extend the analysis extension point so that .ui plugins or other third-party plugins can add outputs to a given analysis that resides in the core.
3376 * Improve the user experience with the analysis:
3377 ** Allow the user to select which analyses should be available, per trace or per project.
3378 ** Allow the user to view all available analyses even though he has no imported traces.
3379 ** Allow the user to generate traces for a given analysis, or generate a template to generate the trace that can be sent as parameter to the tracer.
3380 ** Give the user a visual status of the analysis: not executed, in progress, completed, error.
3381 ** Give a small screenshot of the output as icon for it.
3382 ** Allow to specify parameter values from the GUI.
3383 * Add the possibility for an analysis requirement to be composed of another requirement.
3384 * Generate a trace session from analysis requirements.
3387 = Performance Tests =
3389 Performance testing allows to calculate some metrics (CPU time, Memory Usage, etc) that some part of the code takes during its execution. These metrics can then be used as is for information on the system's execution, or they can be compared either with other execution scenarios, or previous runs of the same scenario, for instance, after some optimization has been done on the code.
3391 For automatic performance metric computation, we use the ''org.eclipse.test.performance'' plugin, provided by the Eclipse Test Feature.
3393 == Add performance tests ==
3397 Performance tests are unit tests and they are added to the corresponding unit tests plugin. To separate performance tests from unit tests, a separate source folder, typically named ''perf'', is added to the plug-in.
3399 Tests are to be added to a package under the ''perf'' directory, the package name would typically match the name of the package it is testing. For each package, a class named '''AllPerfTests''' would list all the performance tests classes inside this package. And like for unit tests, a class named '''AllPerfTests''' for the plug-in would list all the packages' '''AllPerfTests''' classes.
3401 When adding performance tests for the first time in a plug-in, the plug-in's '''AllPerfTests''' class should be added to the global list of performance tests, found in package ''org.eclipse.linuxtools.lttng.alltests'', in class '''RunAllPerfTests'''. This will ensure that performance tests for the plug-in are run along with the other performance tests
3405 TMF is using the org.eclipse.test.performance framework for performance tests. Using this, performance metrics are automatically taken and, if many runs of the tests are run, average and standard deviation are automatically computed. Results can optionally be stored to a database for later use.
3407 Here is an example of how to use the test framework in a performance test:
3410 public class AnalysisBenchmark {
3412 private static final String TEST_ID = "org.eclipse.linuxtools#LTTng kernel analysis";
3413 private static final CtfTmfTestTrace testTrace = CtfTmfTestTrace.TRACE2;
3414 private static final int LOOP_COUNT = 10;
3420 public void testTrace() {
3421 assumeTrue(testTrace.exists());
3423 /** Create a new performance meter for this scenario */
3424 Performance perf = Performance.getDefault();
3425 PerformanceMeter pm = perf.createPerformanceMeter(TEST_ID);
3427 /** Optionally, tag this test for summary or global summary on a given dimension */
3428 perf.tagAsSummary(pm, "LTTng Kernel Analysis", Dimension.CPU_TIME);
3429 perf.tagAsGlobalSummary(pm, "LTTng Kernel Analysis", Dimension.CPU_TIME);
3431 /** The test will be run LOOP_COUNT times */
3432 for (int i = 0; i < LOOP_COUNT; i++) {
3434 /** Start each run of the test with new objects to avoid different code paths */
3435 try (IAnalysisModule module = new LttngKernelAnalysisModule();
3436 LttngKernelTrace trace = new LttngKernelTrace()) {
3437 module.setId("test");
3438 trace.initTrace(null, testTrace.getPath(), CtfTmfEvent.class);
3439 module.setTrace(trace);
3441 /** The analysis execution is being tested, so performance metrics
3442 * are taken before and after the execution */
3444 TmfTestHelper.executeAnalysis(module);
3448 * Delete the supplementary files, so next iteration rebuilds
3451 File suppDir = new File(TmfTraceManager.getSupplementaryFileDir(trace));
3452 for (File file : suppDir.listFiles()) {
3456 } catch (TmfAnalysisException | TmfTraceException e) {
3457 fail(e.getMessage());
3461 /** Once the test has been run many times, committing the results will
3462 * calculate average, standard deviation, and, if configured, save the
3463 * data to a database */
3470 For more information, see [http://wiki.eclipse.org/Performance/Automated_Tests The Eclipse Performance Test How-to]
3472 Some rules to help write performance tests are explained in section [[#ABC of performance testing | ABC of performance testing]].
3474 === Run a performance test ===
3476 Performance tests are unit tests, so, just like unit tests, they can be run by right-clicking on a performance test class and selecting ''Run As'' -> ''Junit Plug-in Test''.
3478 By default, if no database has been configured, results will be displayed in the Console at the end of the test.
3480 Here is the sample output from the test described in the previous section. It shows all the metrics that have been calculated during the test.
3483 Scenario 'org.eclipse.linuxtools#LTTng kernel analysis' (average over 10 samples):
3484 System Time: 3.04s (95% in [2.77s, 3.3s]) Measurable effect: 464ms (1.3 SDs) (required sample size for an effect of 5% of mean: 94)
3485 Used Java Heap: -1.43M (95% in [-33.67M, 30.81M]) Measurable effect: 57.01M (1.3 SDs) (required sample size for an effect of 5% of stdev: 6401)
3486 Working Set: 14.43M (95% in [-966.01K, 29.81M]) Measurable effect: 27.19M (1.3 SDs) (required sample size for an effect of 5% of stdev: 6400)
3487 Elapsed Process: 3.04s (95% in [2.77s, 3.3s]) Measurable effect: 464ms (1.3 SDs) (required sample size for an effect of 5% of mean: 94)
3488 Kernel time: 621ms (95% in [586ms, 655ms]) Measurable effect: 60ms (1.3 SDs) (required sample size for an effect of 5% of mean: 39)
3489 CPU Time: 6.06s (95% in [5.02s, 7.09s]) Measurable effect: 1.83s (1.3 SDs) (required sample size for an effect of 5% of mean: 365)
3490 Hard Page Faults: 0 (95% in [0, 0]) Measurable effect: 0 (1.3 SDs) (required sample size for an effect of 5% of stdev: 6400)
3491 Soft Page Faults: 9.27K (95% in [3.28K, 15.27K]) Measurable effect: 10.6K (1.3 SDs) (required sample size for an effect of 5% of mean: 5224)
3492 Text Size: 0 (95% in [0, 0])
3493 Data Size: 0 (95% in [0, 0])
3494 Library Size: 32.5M (95% in [-12.69M, 77.69M]) Measurable effect: 79.91M (1.3 SDs) (required sample size for an effect of 5% of stdev: 6401)
3497 Results from performance tests can be saved automatically to a derby database. Derby can be run either in embedded mode, locally on a machine, or on a server. More information on setting up derby for performance tests can be found here: [http://wiki.eclipse.org/Performance/Automated_Tests The Eclipse Performance Test How-to]. The following documentation will show how to configure an Eclipse run configuration to store results on a derby database located on a server.
3499 Note that to store results in a derby database, the ''org.apache.derby'' plug-in must be available within your Eclipse. Since it is an optional dependency, it is not included in the target definition. It can be installed via the '''Orbit''' repository, in ''Help'' -> ''Install new software...''. If the '''Orbit''' repository is not listed, click on the latest one from [http://download.eclipse.org/tools/orbit/downloads/] and copy the link under ''Orbit Build Repository''.
3501 To store the data to a database, it needs to be configured in the run configuration. In ''Run'' -> ''Run configurations..'', under ''Junit Plug-in Test'', find the run configuration that corresponds to the test you wish to run, or create one if it is not present yet.
3503 In the ''Arguments'' tab, in the box under ''VM Arguments'', add on separate lines the following information
3506 -Declipse.perf.dbloc=//javaderby.dorsal.polymtl.ca
3507 -Declipse.perf.config=build=mybuild;host=myhost;config=linux;jvm=1.7
3510 The ''eclipse.perf.dbloc'' parameter is the url (or filename) of the derby database. The database is by default named ''perfDB'', with username and password ''guest''/''guest''. If the database does not exist, it will be created, initialized and populated.
3512 The ''eclipse.perf.config'' parameter identifies a '''variation''': It typically identifies the build on which is it run (commitId and/or build date, etc), the machine (host) on which it is run, the configuration of the system (for example Linux or Windows), the jvm etc. That parameter is a list of ';' separated key-value pairs. To be backward-compatible with the Eclipse Performance Tests Framework, the 4 keys mentioned above are mandatory, but any key-value pairs can be used.
3514 == ABC of performance testing ==
3516 Here follow some rules to help design good and meaningful performance tests.
3518 === Determine what to test ===
3520 For tests to be significant, it is important to choose what exactly is to be tested and make sure it is reproducible every run. To limit the amount of noise caused by the TMF framework, the performance test code should be tweaked so that only the method under test is run. For instance, a trace should not be "opened" (by calling the ''traceOpened()'' method) to test an analysis, since the ''traceOpened'' method will also trigger the indexing and the execution of all applicable automatic analysis.
3522 For each code path to test, multiple scenarios can be defined. For instance, an analysis could be run on different traces, with different sizes. The results will show how the system scales and/or varies depending on the objects it is executed on.
3524 The number of '''samples''' used to compute the results is also important. The code to test will typically be inside a '''for''' loop that runs exactly the same code each time for a given number of times. All objects used for the test must start in the same state at each iteration of the loop. For instance, any trace used during an execution should be disposed of at the end of the loop, and any supplementary file that may have been generated in the run should be deleted.
3526 Before submitting a performance test to the code review, you should run it a few times (with results in the Console) and see if the standard deviation is not too large and if the results are reproducible.
3528 === Metrics descriptions and considerations ===
3530 CPU time: CPU time represent the total time spent on CPU by the current process, for the time of the test execution. It is the sum of the time spent by all threads. On one hand, it is more significant than the elapsed time, since it should be the same no matter how many CPU cores the computer has. But since it calculates the time of every thread, one has to make sure that only threads related to what is being tested are executed during that time, or else the results will include the times of those other threads. For an application like TMF, it is hard to control all the threads, and empirically, it is found to vary a lot more than the system time from one run to the other.
3532 System time (Elapsed time): The time between the start and the end of the execution. It will vary depending on the parallelisation of the threads and the load of the machine.
3534 Kernel time: Time spent in kernel mode
3536 Used Java Heap: It is the difference between the memory used at the beginning of the execution and at the end. This metric may be useful to calculate the overall size occupied by the data generated by the test run, by forcing a garbage collection before taking the metrics at the beginning and at the end of the execution. But it will not show the memory used throughout the execution. There can be a large standard deviation. The reason for this is that when benchmarking methods that trigger tasks in different threads, like signals and/or analysis, these other threads might be in various states at each run of the test, which will impact the memory usage calculated. When using this metric, either make sure the method to test does not trigger external threads or make sure you wait for them to finish.
3540 == Adding a protocol ==
3542 Supporting a new network protocol in TMF is straightforward. Minimal effort is required to support new protocols. In this tutorial, the UDP protocol will be added to the list of supported protocols.
3544 === Architecture ===
3546 All the TMF pcap-related code is divided in three projects (not considering the tests plugins):
3547 * '''org.eclipse.linuxtools.pcap.core''', which contains the parser that will read pcap files and constructs the different packets from a ByteBuffer. It also contains means to build packet streams, which are conversation (list of packets) between two endpoints. To add a protocol, almost all of the work will be in that project.
3548 * '''org.eclipse.linuxtools.tmf.pcap.core''', which contains TMF-specific concepts and act as a wrapper between TMF and the pcap parsing library. It only depends on org.eclipse.linuxtools.tmf.core and org.eclipse.pcap.core. To add a protocol, one file must be edited in this project.
3549 * '''org.eclipse.linuxtools.tmf.pcap.ui''', which contains all TMF pcap UI-specific concepts, such as the views and perspectives. No work is needed in that project.
3551 === UDP Packet Structure ===
3553 The UDP is a transport-layer protocol that does not guarantee message delivery nor in-order message reception. A UDP packet (datagram) has the following [http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure structure]:
3555 {| class="wikitable" style="margin: 0 auto; text-align: center;"
3557 ! style="border-bottom:none; border-right:none;"| ''Offsets''
3558 ! style="border-left:none;"| Octet
3564 ! style="border-top: none" | Octet
3565 ! <tt>Bit</tt>!!<tt> 0</tt>!!<tt> 1</tt>!!<tt> 2</tt>!!<tt> 3</tt>!!<tt> 4</tt>!!<tt> 5</tt>!!<tt> 6</tt>!!<tt> 7</tt>!!<tt> 8</tt>!!<tt> 9</tt>!!<tt>10</tt>!!<tt>11</tt>!!<tt>12</tt>!!<tt>13</tt>!!<tt>14</tt>!!<tt>15</tt>!!<tt>16</tt>!!<tt>17</tt>!!<tt>18</tt>!!<tt>19</tt>!!<tt>20</tt>!!<tt>21</tt>!!<tt>22</tt>!!<tt>23</tt>!!<tt>24</tt>!!<tt>25</tt>!!<tt>26</tt>!!<tt>27</tt>!!<tt>28</tt>!!<tt>29</tt>!!<tt>30</tt>!!<tt>31</tt>
3569 | colspan="16" style="background:#fdd;"| Source port || colspan="16"| Destination port
3573 | colspan="16"| Length || colspan="16" style="background:#fdd;"| Checksum
3576 Knowing that, we can define an UDPPacket class that contains those fields.
3578 === Creating the UDPPacket ===
3580 First, in org.eclipse.linuxtools.pcap.core, create a new package named '''org.eclipse.linuxtools.pcap.core.protocol.name''' with name being the name of the new protocol. In our case name is udp so we create the package '''org.eclipse.linuxtools.pcap.core.protocol.udp'''. All our work is going in this package.
3582 In this package, we create a new class named UDPPacket that extends Packet. All new protocol must define a packet type that extends the abstract class Packet. We also add different fields:
3583 * ''Packet'' '''fChildPacket''', which is the packet encapsulated by this UDP packet, if it exists. This field will be initialized by findChildPacket().
3584 * ''ByteBuffer'' '''fPayload''', which is the payload of this packet. Basically, it is the UDP packet without its header.
3585 * ''int'' '''fSourcePort''', which is an unsigned 16-bits field, that contains the source port of the packet (see packet structure).
3586 * ''int'' '''fDestinationPort''', which is an unsigned 16-bits field, that contains the destination port of the packet (see packet structure).
3587 * ''int'' '''fTotalLength''', which is an unsigned 16-bits field, that contains the total length (header + payload) of the packet.
3588 * ''int'' '''fChecksum''', which is an unsigned 16-bits field, that contains a checksum to verify the integrity of the data.
3589 * ''UDPEndpoint'' '''fSourceEndpoint''', which contains the source endpoint of the UDPPacket. The UDPEndpoint class will be created later in this tutorial.
3590 * ''UDPEndpoint'' '''fDestinationEndpoint''', which contains the destination endpoint of the UDPPacket.
3591 * ''ImmutableMap<String, String>'' '''fFields''', which is a map that contains all the packet fields (see in data structure) which assign a field name with its value. Those values will be displayed on the UI.
3593 We also create the UDPPacket(PcapFile file, @Nullable Packet parent, ByteBuffer packet) constructor. The parameters are:
3594 * ''PcapFile'' '''file''', which is the pcap file to which this packet belongs.
3595 * ''Packet'' '''parent''', which is the packet encasulating this UDPPacket
3596 * ''ByteBuffer'' '''packet''', which is a ByteBuffer that contains all the data necessary to initialize the fields of this UDPPacket. We will retrieve bytes from it during object construction.
3598 The following class is obtained:
3601 package org.eclipse.linuxtools.pcap.core.protocol.udp;
3603 import java.nio.ByteBuffer;
3604 import java.util.Map;
3606 import org.eclipse.linuxtools.internal.pcap.core.endpoint.ProtocolEndpoint;
3607 import org.eclipse.linuxtools.internal.pcap.core.packet.BadPacketException;
3608 import org.eclipse.linuxtools.internal.pcap.core.packet.Packet;
3610 public class UDPPacket extends Packet {
3612 private final @Nullable Packet fChildPacket;
3613 private final @Nullable ByteBuffer fPayload;
3615 private final int fSourcePort;
3616 private final int fDestinationPort;
3617 private final int fTotalLength;
3618 private final int fChecksum;
3620 private @Nullable UDPEndpoint fSourceEndpoint;
3621 private @Nullable UDPEndpoint fDestinationEndpoint;
3623 private @Nullable ImmutableMap<String, String> fFields;
3626 * Constructor of the UDP Packet class.
3629 * The file that contains this packet.
3631 * The parent packet of this packet (the encapsulating packet).
3633 * The entire packet (header and payload).
3634 * @throws BadPacketException
3635 * Thrown when the packet is erroneous.
3637 public UDPPacket(PcapFile file, @Nullable Packet parent, ByteBuffer packet) throws BadPacketException {
3638 super(file, parent, Protocol.UDP);
3639 // TODO Auto-generated constructor stub
3644 public Packet getChildPacket() {
3645 // TODO Auto-generated method stub
3650 public ByteBuffer getPayload() {
3651 // TODO Auto-generated method stub
3656 public boolean validate() {
3657 // TODO Auto-generated method stub
3662 protected Packet findChildPacket() throws BadPacketException {
3663 // TODO Auto-generated method stub
3668 public ProtocolEndpoint getSourceEndpoint() {
3669 // TODO Auto-generated method stub
3674 public ProtocolEndpoint getDestinationEndpoint() {
3675 // TODO Auto-generated method stub
3680 public Map<String, String> getFields() {
3681 // TODO Auto-generated method stub
3686 public String getLocalSummaryString() {
3687 // TODO Auto-generated method stub
3692 protected String getSignificationString() {
3693 // TODO Auto-generated method stub
3698 public boolean equals(Object obj) {
3699 // TODO Auto-generated method stub
3704 public int hashCode() {
3705 // TODO Auto-generated method stub
3712 Now, we implement the constructor. It is done in four steps:
3713 * We initialize fSourceEndpoint, fDestinationEndpoint and fFields to null, since those are lazy-loaded. This allows faster construction of the packet and thus faster parsing.
3714 * We initialize fSourcePort, fDestinationPort, fTotalLength, fChecksum using ByteBuffer packet. Thanks to the packet data structure, we can simply retrieve packet.getShort() to get the value. Since there is no unsigned in Java, special care is taken to avoid negative number. We use the utility method ConversionHelper.unsignedShortToInt() to convert it to an integer, and initialize the fields.
3715 * Now that the header is parsed, we take the rest of the ByteBuffer packet to initialize the payload, if there is one. To do this, we simply generate a new ByteBuffer starting from the current position.
3716 * We initialize the field fChildPacket using the method findChildPacket()
3718 The following constructor is obtained:
3720 public UDPPacket(PcapFile file, @Nullable Packet parent, ByteBuffer packet) throws BadPacketException {
3721 super(file, parent, Protocol.UDP);
3723 // The endpoints and fFields are lazy loaded. They are defined in the get*Endpoint()
3725 fSourceEndpoint = null;
3726 fDestinationEndpoint = null;
3729 // Initialize the fields from the ByteBuffer
3730 packet.order(ByteOrder.BIG_ENDIAN);
3733 fSourcePort = ConversionHelper.unsignedShortToInt(packet.getShort());
3734 fDestinationPort = ConversionHelper.unsignedShortToInt(packet.getShort());
3735 fTotalLength = ConversionHelper.unsignedShortToInt(packet.getShort());
3736 fChecksum = ConversionHelper.unsignedShortToInt(packet.getShort());
3738 // Initialize the payload
3739 if (packet.array().length - packet.position() > 0) {
3740 byte[] array = new byte[packet.array().length - packet.position()];
3743 ByteBuffer payload = ByteBuffer.wrap(array);
3744 payload.order(ByteOrder.BIG_ENDIAN);
3745 payload.position(0);
3752 fChildPacket = findChildPacket();
3757 Then, we implement the following methods:
3758 * ''public Packet'' '''getChildPacket()''': simple getter of fChildPacket
3759 * ''public ByteBuffer'' '''getPayload()''': simple getter of fPayload
3760 * ''public boolean'' '''validate()''': method that checks if the packet is valid. In our case, the packet is valid if the retrieved checksum fChecksum and the real checksum (that we can compute using the fields and payload of UDPPacket) are the same.
3761 * ''protected Packet'' '''findChildPacket()''': method that create a new packet if a encapsulated protocol is found. For instance, based on the fDestinationPort, it could determine what the encapsulated protocol is and creates a new packet object.
3762 * ''public ProtocolEndpoint'' '''getSourceEndpoint()''': method that initializes and returns the source endpoint.
3763 * ''public ProtocolEndpoint'' '''getDestinationEndpoint()''': method that initializes and returns the destination endpoint.
3764 * ''public Map<String, String>'' '''getFields()''': method that initializes and returns the map containing the fields matched to their value.
3765 * ''public String'' '''getLocalSummaryString()''': method that returns a string summarizing the most important fields of the packet. There is no need to list all the fields, just the most important one. This will be displayed on UI.
3766 * ''protected String'' '''getSignificationString()''': method that returns a string describing the meaning of the packet. If there is no particular meaning, it is possible to return getLocalSummaryString().
3767 * public boolean'' '''equals(Object obj)''': Object's equals method.
3768 * public int'' '''hashCode()''': Object's hashCode method.
3770 We get the following code:
3773 public @Nullable Packet getChildPacket() {
3774 return fChildPacket;
3778 public @Nullable ByteBuffer getPayload() {
3783 * Getter method that returns the UDP Source Port.
3785 * @return The source Port.
3787 public int getSourcePort() {
3792 * Getter method that returns the UDP Destination Port.
3794 * @return The destination Port.
3796 public int getDestinationPort() {
3797 return fDestinationPort;
3803 * See http://www.iana.org/assignments/service-names-port-numbers/service-
3804 * names-port-numbers.xhtml or
3805 * http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
3808 protected @Nullable Packet findChildPacket() throws BadPacketException {
3809 // When more protocols are implemented, we can simply do a switch on the fDestinationPort field to find the child packet.
3810 // For instance, if the destination port is 80, then chances are the HTTP protocol is encapsulated. We can create a new HTTP
3811 // packet (after some verification that it is indeed the HTTP protocol).
3812 ByteBuffer payload = fPayload;
3813 if (payload == null) {
3817 return new UnknownPacket(getPcapFile(), this, payload);
3821 public boolean validate() {
3822 // Not yet implemented. ATM, we consider that all packets are valid.
3823 // TODO Implement it. We can compute the real checksum and compare it to fChecksum.
3828 public UDPEndpoint getSourceEndpoint() {
3830 UDPEndpoint endpoint = fSourceEndpoint;
3831 if (endpoint == null) {
3832 endpoint = new UDPEndpoint(this, true);
3834 fSourceEndpoint = endpoint;
3835 return fSourceEndpoint;
3839 public UDPEndpoint getDestinationEndpoint() {
3840 @Nullable UDPEndpoint endpoint = fDestinationEndpoint;
3841 if (endpoint == null) {
3842 endpoint = new UDPEndpoint(this, false);
3844 fDestinationEndpoint = endpoint;
3845 return fDestinationEndpoint;
3849 public Map<String, String> getFields() {
3850 ImmutableMap<String, String> map = fFields;
3852 @SuppressWarnings("null")
3853 @NonNull ImmutableMap<String, String> newMap = ImmutableMap.<String, String> builder()
3854 .put("Source Port", String.valueOf(fSourcePort)) //$NON-NLS-1$
3855 .put("Destination Port", String.valueOf(fDestinationPort)) //$NON-NLS-1$
3856 .put("Length", String.valueOf(fTotalLength) + " bytes") //$NON-NLS-1$ //$NON-NLS-2$
3857 .put("Checksum", String.format("%s%04x", "0x", fChecksum)) //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
3866 public String getLocalSummaryString() {
3867 return "Src Port: " + fSourcePort + ", Dst Port: " + fDestinationPort; //$NON-NLS-1$ //$NON-NLS-2$
3871 protected String getSignificationString() {
3872 return "Source Port: " + fSourcePort + ", Destination Port: " + fDestinationPort; //$NON-NLS-1$ //$NON-NLS-2$
3876 public int hashCode() {
3877 final int prime = 31;
3879 result = prime * result + fChecksum;
3880 final Packet child = fChildPacket;
3881 if (child != null) {
3882 result = prime * result + child.hashCode();
3884 result = prime * result;
3886 result = prime * result + fDestinationPort;
3887 final ByteBuffer payload = fPayload;
3888 if (payload != null) {
3889 result = prime * result + payload.hashCode();
3891 result = prime * result;
3893 result = prime * result + fSourcePort;
3894 result = prime * result + fTotalLength;
3899 public boolean equals(@Nullable Object obj) {
3906 if (getClass() != obj.getClass()) {
3909 UDPPacket other = (UDPPacket) obj;
3910 if (fChecksum != other.fChecksum) {
3913 final Packet child = fChildPacket;
3914 if (child != null) {
3915 if (!child.equals(other.fChildPacket)) {
3919 if (other.fChildPacket != null) {
3923 if (fDestinationPort != other.fDestinationPort) {
3926 final ByteBuffer payload = fPayload;
3927 if (payload != null) {
3928 if (!payload.equals(other.fPayload)) {
3932 if (other.fPayload != null) {
3936 if (fSourcePort != other.fSourcePort) {
3939 if (fTotalLength != other.fTotalLength) {
3946 The UDPPacket class is implemented. We now have the define the UDPEndpoint.
3948 === Creating the UDPEndpoint ===
3950 For the UDP protocol, an endpoint will be its source or its destination port, depending if it is the source endpoint or destination endpoint. Knowing that, we can create our UDPEndpoint class.
3952 We create in our package a new class named UDPEndpoint that extends ProtocolEndpoint. We also add a field: fPort, which contains the source or destination port. We finally add a constructor public ExampleEndpoint(Packet packet, boolean isSourceEndpoint):
3953 * ''Packet'' '''packet''': the packet to build the endpoint from.
3954 * ''boolean'' '''isSourceEndpoint''': whether the endpoint is the source endpoint or destination endpoint.
3956 We obtain the following unimplemented class:
3959 package org.eclipse.linuxtools.pcap.core.protocol.udp;
3961 import org.eclipse.linuxtools.internal.pcap.core.endpoint.ProtocolEndpoint;
3962 import org.eclipse.linuxtools.internal.pcap.core.packet.Packet;
3964 public class UDPEndpoint extends ProtocolEndpoint {
3966 private final int fPort;
3968 public UDPEndpoint(Packet packet, boolean isSourceEndpoint) {
3969 super(packet, isSourceEndpoint);
3970 // TODO Auto-generated constructor stub
3974 public int hashCode() {
3975 // TODO Auto-generated method stub
3980 public boolean equals(Object obj) {
3981 // TODO Auto-generated method stub
3986 public String toString() {
3987 // TODO Auto-generated method stub
3994 For the constructor, we simply initialize fPort. If isSourceEndpoint is true, then we take packet.getSourcePort(), else we take packet.getDestinationPort().
3998 * Constructor of the {@link UDPEndpoint} class. It takes a packet to get
3999 * its endpoint. Since every packet has two endpoints (source and
4000 * destination), the isSourceEndpoint parameter is used to specify which
4004 * The packet that contains the endpoints.
4005 * @param isSourceEndpoint
4006 * Whether to take the source or the destination endpoint of the
4009 public UDPEndpoint(UDPPacket packet, boolean isSourceEndpoint) {
4010 super(packet, isSourceEndpoint);
4011 fPort = isSourceEndpoint ? packet.getSourcePort() : packet.getDestinationPort();
4015 Then we implement the methods:
4016 * ''public int'' '''hashCode()''': method that returns an integer based on the fields value. In our case, it will return an integer depending on fPort, and the parent endpoint that we can retrieve with getParentEndpoint().
4017 * ''public boolean'' '''equals(Object obj)''': method that returns true if two objects are equals. In our case, two UDPEndpoints are equal if they both have the same fPort and have the same parent endpoint that we can retrieve with getParentEndpoint().
4018 * ''public String'' '''toString()''': method that returns a description of the UDPEndpoint as a string. In our case, it will be a concatenation of the string of the parent endpoint and fPort as a string.
4022 public int hashCode() {
4023 final int prime = 31;
4025 ProtocolEndpoint endpoint = getParentEndpoint();
4026 if (endpoint == null) {
4029 result = endpoint.hashCode();
4031 result = prime * result + fPort;
4036 public boolean equals(@Nullable Object obj) {
4040 if (!(obj instanceof UDPEndpoint)) {
4044 UDPEndpoint other = (UDPEndpoint) obj;
4047 boolean localEquals = (fPort == other.fPort);
4052 // Check above layers.
4053 ProtocolEndpoint endpoint = getParentEndpoint();
4054 if (endpoint != null) {
4055 return endpoint.equals(other.getParentEndpoint());
4061 public String toString() {
4062 ProtocolEndpoint endpoint = getParentEndpoint();
4063 if (endpoint == null) {
4064 @SuppressWarnings("null")
4065 @NonNull String ret = String.valueOf(fPort);
4068 return endpoint.toString() + '/' + fPort;
4072 === Registering the UDP protocol ===
4074 The last step is to register the new protocol. There are three places where the protocol has to be registered. First, the parser has to know that a new protocol has been added. This is defined in the enum org.eclipse.linuxtools.pcap.core.protocol.PcapProtocol. Simply add the protocol name here, along with a few arguments:
4075 * ''String'' '''longname''', which is the long version of name of the protocol. In our case, it is "User Datagram Protocol".
4076 * ''String'' '''shortName''', which is the shortened name of the protocol. In our case, it is "UDP".
4077 * ''Layer'' '''layer''', which is the layer to which the protocol belongs in the OSI model. In our case, this is the layer 4.
4078 * ''boolean'' '''supportsStream''', which defines whether or not the protocol supports packet streams. In our case, this is set to true.
4080 Thus, the following line is added in the PcapProtocol enum:
4082 UDP("User Datagram Protocol", "udp", Layer.LAYER_4, true),
4085 Also, TMF has to know about the new protocol. This is defined in org.eclipse.linuxtools.tmf.pcap.core.protocol.TmfPcapProtocol. We simply add it, with a reference to the corresponding protocol in PcapProtocol. Thus, the following line is added in the TmfPcapProtocol enum:
4087 UDP(PcapProtocol.UDP),
4090 You will also have to update the ''ProtocolConversion'' class to register the protocol in the switch statements. Thus, for UDP, we add:
4093 return TmfPcapProtocol.UDP;
4098 return PcapProtocol.UDP;
4101 Finally, all the protocols that could be the parent of the new protocol (in our case, IPv4 and IPv6) have to be notified of the new protocol. This is done by modifying the findChildPacket() method of the packet class of those protocols. For instance, in IPv4Packet, we add a case in the switch statement of findChildPacket, if the Protocol number matches UDP's protocol number at the network layer:
4104 protected @Nullable Packet findChildPacket() throws BadPacketException {
4105 ByteBuffer payload = fPayload;
4106 if (payload == null) {
4110 switch (fIpDatagramProtocol) {
4111 case IPProtocolNumberHelper.PROTOCOL_NUMBER_TCP:
4112 return new TCPPacket(getPcapFile(), this, payload);
4113 case IPProtocolNumberHelper.PROTOCOL_NUMBER_UDP:
4114 return new UDPPacket(getPcapFile(), this, payload);
4116 return new UnknownPacket(getPcapFile(), this, payload);
4121 The new protocol has been added. Running TMF should work just fine, and the new protocol is now recognized.
4123 == Adding stream-based views ==
4125 To add a stream-based View, simply monitor the TmfPacketStreamSelectedSignal in your view. It contains the new stream that you can retrieve with signal.getStream(). You must then make an event request to the current trace to get the events, and use the stream to filter the events of interest. Therefore, you must also monitor TmfTraceOpenedSignal, TmfTraceClosedSignal and TmfTraceSelectedSignal. Examples of stream-based views include a view that represents the packets as a sequence diagram, or that shows the TCP connection state based on the packets SYN/ACK/FIN/RST flags. A (very very very early) draft of such a view can be found at https://git.eclipse.org/r/#/c/31054/.
4129 * Add more protocols. At the moment, only four protocols are supported. The following protocols would need to be implemented: ARP, SLL, WLAN, USB, IPv6, ICMP, ICMPv6, IGMP, IGMPv6, SCTP, DNS, FTP, HTTP, RTP, SIP, SSH and Telnet. Other VoIP protocols would be nice.
4130 * Add a network graph view. It would be useful to produce graphs that are meaningful to network engineers, and that they could use (for presentation purpose, for instance). We could use the XML-based analysis to do that!
4131 * Add a Stream Diagram view. This view would represent a stream as a Sequence Diagram. It would be updated when a TmfNewPacketStreamSignal is thrown. It would be easy to see the packet exchange and the time delta between each packet. Also, when a packet is selected in the Stream Diagram, it should be selected in the event table and its content should be shown in the Properties View. See https://git.eclipse.org/r/#/c/31054/ for a draft of such a view.
4132 * Make adding protocol more "plugin-ish", via extension points for instance. This would make it easier to support new protocols, without modifying the source code.
4133 * Control dumpcap directly from eclipse, similar to how LTTng is controlled in the Control View.
4134 * Support pcapng. See: http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html for the file format.
4135 * Add SWTBOT tests to org.eclipse.linuxtools.tmf.pcap.ui
4136 * Add a Raw Viewer, similar to Wireshark. We could use the “Show Raw” in the event editor to do that.
4137 * Externalize strings in org.eclipse.linuxtools.pcap.core. At the moment, all the strings are hardcoded. It would be good to externalize them all.