luxolus
/
open-nomad
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-nomad/client/lib/fifo/fifo_test.go

142 lines
2.6 KiB
Go
Raw Normal View History

fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
package fifo
import (
"bytes"
"io"
"io/ioutil"
"os"
"path/filepath"
"runtime"
"sync"
"testing"
"time"
"github.com/hashicorp/nomad/helper/uuid"
no requires in a test goroutine
2019-04-01 19:38:39 +00:00
"github.com/stretchr/testify/assert"
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
"github.com/stretchr/testify/require"
)
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
// TestFIFO tests basic behavior, and that reader closes when writer closes
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
func TestFIFO(t *testing.T) {
require := require.New(t)
var path string
if runtime.GOOS == "windows" {
path = "//./pipe/fifo"
} else {
dir, err := ioutil.TempDir("", "")
require.NoError(err)
defer os.RemoveAll(dir)
path = filepath.Join(dir, "fifo")
}
rename fifo methods for clarity
2019-04-01 19:56:43 +00:00
readerOpenFn, err := CreateAndRead(path)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
require.NoError(err)
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
var reader io.ReadCloser
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
toWrite := [][]byte{
[]byte("abc\n"),
[]byte(""),
[]byte("def\n"),
[]byte("nomad"),
[]byte("\n"),
}
var readBuf bytes.Buffer
var wait sync.WaitGroup
wait.Add(1)
go func() {
defer wait.Done()
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
tests: fix fifo lib race Accidentally accessed outer `err` variable inside a goroutine
2019-05-21 13:32:58 +00:00
var err error
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
reader, err = readerOpenFn()
no requires in a test goroutine
2019-04-01 19:38:39 +00:00
assert.NoError(t, err)
if err != nil {
return
}
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
_, err = io.Copy(&readBuf, reader)
no requires in a test goroutine
2019-04-01 19:38:39 +00:00
assert.NoError(t, err)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
}()
rename fifo methods for clarity
2019-04-01 19:56:43 +00:00
writer, err := OpenWriter(path)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
require.NoError(err)
for _, b := range toWrite {
n, err := writer.Write(b)
require.NoError(err)
require.Equal(n, len(b))
}
require.NoError(writer.Close())
time.Sleep(500 * time.Millisecond)
wait.Wait()
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
require.NoError(reader.Close())
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
expected := "abc\ndef\nnomad\n"
require.Equal(expected, readBuf.String())
require.NoError(Remove(path))
}
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
// TestWriteClose asserts that when writer closes, subsequent Write() fails
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
func TestWriteClose(t *testing.T) {
require := require.New(t)
var path string
if runtime.GOOS == "windows" {
path = "//./pipe/" + uuid.Generate()[:4]
} else {
dir, err := ioutil.TempDir("", "")
require.NoError(err)
defer os.RemoveAll(dir)
path = filepath.Join(dir, "fifo")
}
rename fifo methods for clarity
2019-04-01 19:56:43 +00:00
readerOpenFn, err := CreateAndRead(path)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
require.NoError(err)
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
var reader io.ReadCloser
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
var readBuf bytes.Buffer
var wait sync.WaitGroup
wait.Add(1)
go func() {
defer wait.Done()
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
tests: fix fifo lib race Accidentally accessed outer `err` variable inside a goroutine
2019-05-21 13:32:58 +00:00
var err error
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
reader, err = readerOpenFn()
no requires in a test goroutine
2019-04-01 19:38:39 +00:00
assert.NoError(t, err)
if err != nil {
return
}
fifo: Use plain fifo file in Unix This PR switches to using plain fifo files instead of golang structs managed by containerd/fifo library. The library main benefit is management of opening fifo files. In Linux, a reader `open()` request would block until a writer opens the file (and vice-versa). The library uses goroutines so that it's the first IO operation that blocks. This benefit isn't really useful for us: Given that logmon simply streams output in a separate process, blocking of opening or first read is effectively the same. The library additionally makes further complications for managing state and tracking read/write permission that seems overhead for our use, compared to using a file directly. Looking here, I made the following incidental changes: * document that we do handle if fifo files are already created, as we rely on that behavior for logmon restarts * use type system to lock read vs write: currently, fifo library returns `io.ReadWriteCloser` even if fifo is opened for writing only!
2019-03-31 16:50:06 +00:00
_, err = io.Copy(&readBuf, reader)
no requires in a test goroutine
2019-04-01 19:38:39 +00:00
assert.NoError(t, err)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
}()
rename fifo methods for clarity
2019-04-01 19:56:43 +00:00
writer, err := OpenWriter(path)
fifo: add new fifo package for named pipes (#4665) * fifo: add new fifo package for named pipes
2018-09-17 17:15:48 +00:00
require.NoError(err)
var count int
wait.Add(1)
go func() {
defer wait.Done()
for count = 0; count < int(^uint16(0)); count++ {
_, err := writer.Write([]byte(","))
if err != nil && IsClosedErr(err) {
break
}
require.NoError(err)
time.Sleep(5 * time.Millisecond)
}
}()
time.Sleep(500 * time.Millisecond)
require.NoError(writer.Close())
wait.Wait()
require.Equal(count, len(readBuf.String()))
}