tmf: Handle empty traces with the abstract state provider
authorAlexandre Montplaisir <alexmonthy@voxpopuli.im>
Wed, 5 Feb 2014 19:20:31 +0000 (14:20 -0500)
committerAlexandre Montplaisir <alexmonthy@voxpopuli.im>
Thu, 6 Feb 2014 22:50:48 +0000 (17:50 -0500)
Traces with state systems using the AbstractTmfStateProvider (ie,
all of them) would not get closed correctly if no event was ever
received in the provider - currentEvent would remain null, and the
closing step would be skipped.

This is probably an artifact back from the time where history backends
were optional. Now the closing step should always be run, and if we do
not have a valid end time to define, simply use 0. The dummy state
system will go from MIN_VALUE to 0, and since it will have absolutely
no data in it, it really doesn't matter.

Change-Id: Ia36d7bb2cce0b5712825043c7d9becd85cd7ec35
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
Reviewed-on: https://git.eclipse.org/r/21576
Tested-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
IP-Clean: Matthew Khouzam <matthew.khouzam@ericsson.com>

org.eclipse.linuxtools.tmf.core/src/org/eclipse/linuxtools/internal/tmf/core/statesystem/backends/historytree/HT_IO.java
org.eclipse.linuxtools.tmf.core/src/org/eclipse/linuxtools/tmf/core/statesystem/AbstractTmfStateProvider.java

index 1c0257a3aa019935cf67a6bba95fdb1a502cdd79..e8441e5d3b44e62255592ea5ee6535c74bb21ade 100644 (file)
@@ -122,7 +122,7 @@ class HT_IO {
         }
     }
 
-    public void writeNode(HTNode node) {
+    public synchronized void writeNode(HTNode node) {
         try {
             /* Insert the node into the cache. */
             int seqNumber = node.getSequenceNumber();
@@ -138,7 +138,7 @@ class HT_IO {
         }
     }
 
-    public  FileChannel getFcOut() {
+    public FileChannel getFcOut() {
         return this.fcOut;
     }
 
index bf48c6066110db0dec82700f26021cf962182672..fb17295cb9f79e85a7f77cba30effbdc9e5c9fa3 100644 (file)
@@ -18,7 +18,6 @@ import java.util.concurrent.BlockingQueue;
 import org.eclipse.linuxtools.tmf.core.ctfadaptor.CtfTmfEventFactory;
 import org.eclipse.linuxtools.tmf.core.event.ITmfEvent;
 import org.eclipse.linuxtools.tmf.core.event.TmfEvent;
-import org.eclipse.linuxtools.tmf.core.exceptions.TimeRangeException;
 import org.eclipse.linuxtools.tmf.core.timestamp.ITmfTimestamp;
 import org.eclipse.linuxtools.tmf.core.timestamp.TmfTimestamp;
 import org.eclipse.linuxtools.tmf.core.trace.ITmfTrace;
@@ -47,7 +46,6 @@ public abstract class AbstractTmfStateProvider implements ITmfStateProvider {
     private final Thread eventHandlerThread;
 
     private boolean ssAssigned;
-    private ITmfEvent currentEvent;
 
     /** State system in which to insert the state changes */
     protected ITmfStateSystemBuilder ss = null;
@@ -172,6 +170,8 @@ public abstract class AbstractTmfStateProvider implements ITmfStateProvider {
      */
     private class EventProcessor implements Runnable {
 
+        private ITmfEvent currentEvent;
+
         @Override
         public void run() {
             if (ss == null) {
@@ -207,19 +207,9 @@ public abstract class AbstractTmfStateProvider implements ITmfStateProvider {
         }
 
         private void closeStateSystem() {
-            /* Close the History system, if there is one */
-            if (currentEvent == null) {
-                return;
-            }
-            try {
-                ss.closeHistory(currentEvent.getTimestamp().normalize(0, ITmfTimestamp.NANOSECOND_SCALE).getValue());
-            } catch (TimeRangeException e) {
-                /*
-                 * Since we're using currentEvent.getTimestamp, this shouldn't
-                 * cause any problem
-                 */
-                e.printStackTrace();
-            }
+            final long endTime = (currentEvent == null) ? 0 :
+                    currentEvent.getTimestamp().normalize(0, ITmfTimestamp.NANOSECOND_SCALE).getValue();
+            ss.closeHistory(endTime);
         }
     }
 
This page took 0.027823 seconds and 5 git commands to generate.