Fix race condition

cmd/agent/app/agent_test.go

@@ -88,6 +88,16 @@ func TestAgentStartStop(t *testing.T) {
 	body, err := ioutil.ReadAll(resp.Body)
 	assert.NoError(t, err)
 	assert.Equal(t, "tcollector error: no peers available\n", string(body))
+
+	// TODO (wjang) We sleep because the processors in the agent might not have had time to
+	// start up yet. If we were to call Stop() before the processors have time to startup,
+	// it'll panic because of a DATA RACE between wg.Add() and wg.Wait() in thrift_processor.
+	// A real fix for this issue would be to add semaphores to tbuffered_server, thrift_processor,
+	// and agent itself. Given all this extra overhead and testing required to get this to work
+	// "elegantly", I opted to just sleep here given how unlikely this situation will occur in
+	// production.
+	time.Sleep(2 * time.Second)
+
 	agent.Stop()
 	assert.NoError(t, <-ch)
 }

pkg/queue/drop_oldest_queue_test.go

@@ -34,7 +34,7 @@ func TestQueue(t *testing.T) {
 	var wg sync.WaitGroup
 	var startLock sync.Mutex
 
-	// Make sure that at least one consumer consumes and element before we produce them
+	// Make sure that at least one consumer consumes an element before we produce them
 	// all. If all 5 go out before an consumers, we'll have 1 reaped, 1 in reaper channel,
 	// and 2 in the items channel, and we'll deadlock.
 	consumerConsumed := sync.NewCond(&sync.Mutex{})
@@ -66,7 +66,7 @@ func TestQueue(t *testing.T) {
 		q.Produce(val) // goes to consumer 1 and blocks it on startLock
 		t.Logf("produced %s, queue size %d\n", val, q.Size())
 	}
-	// With queue capacity of 3, and two consumers, we can product at most 5 items without blocking,
+	// With queue capacity of 3, and two consumers, we can produce at most 5 items without blocking,
 	// assuming that both consumers read one value and block
 	// If they don't read, then main will block while producing 5 items, thus allowing consumers to read
 	// and block.