Using the firedrill and master branch as an example, if step 4 (start a forth) is run after the store revision number has passed the -hist parameter, the new instance panics with TOO_LATE

It's also easy to reproduce by setting a low -hist on the first instance and waiting to start another until the pulse has made rev > hist.

The stack trace begins:

panic: TOO_LATE

goroutine 1 [running]:
doozer/peer.cloner.VisitFile(0xf840051410, 0xf840001960, 0xf840019d60, 0xa, 0xf84004e3f0, ...)
    /home/dcoates/code/doozerd/src/pkg/peer/peer.go:298 +0xc0
doozer/peer.(*cloner).VisitFile(0xf840019a60, 0xf840019d60, 0xf80000000a, 0xf84004e3f0, 0x1, ...)
    /home/dcoates/code/doozerd/src/pkg/peer/peer.go:0 +0x8b
github.com/ha/doozer.walk(0xf840001960, 0x8f, 0xf840019d60, 0xf80000000a, 0xf84004e3f0, ...)
    /home/dcoates/code/doozer/walk.go:23 +0x64

It appears that the Clean in clean.go (line 352) on the store initiated by a goroutine in peer.go (line 62) is causing the Get in peer.go (line 296) to return ErrTooLate because the rev of some path (in my case /ctl/cal/0 at rev 5) is less than st.head

This seems like a bug, but I may be misunderstanding.

What is the proper way to add a new doozerd to a cluster after the rev has passed hist? This seems like a pretty basic operation to do if an instance crashes.

I've downloaded this binary: https://github.com/downloads/ha/doozerd/doozerd-0.8-darwin-amd64.tar.gz Unpacked, chmodded and tried to run. Getting following error:

./doozerd
libcgo: thread-local storage 0x108 not at %gs:0x8a0 - x=0 y=0
[1]    21635 abort      ./doozerd

it allows you to deterministically identify a running node... this has been helpful for our use of doozerd at bitly particularly in scripts for cluster setup and daemon instantiation

ready for review @kr

matching pull request for client code on https://github.com/ha/doozer coming up

Currently, 4ad/doozerd compiles against go1 and is more actively maintained. A support ticket to Github made by @ha could "flip" the fork status of the ha/doozerd and 4ad/doozerd.

Similarly, with ha/doozer and 4ad/doozer, I believe.

This would make it more clear to new users which repo is more available (and might help clear up the strong google juice ha/doozerd has over 4ad's).

this makes doozer compile with go r59. Two types of problems occured to me:

1.) some function signatures changed 2.) the provided generated protobuffer files did not work for me, i.e. I removed *.pb.go files from the repository and added them to be removed when clean is called -- they get auto generated when all.sh is executed.

I get this error when running make.sh:

package github.com/ha/doozer
    imports code.google.com/p/goprotobuf/proto
    imports github.com/kr/pretty.go
    imports github.com/kr/pretty.go
    imports github.com/kr/pretty.go: no Go source files in .go/src/github.com/kr/pretty.go

the problem seemed to be that the server would infinite loop due to nop events having rev == -3... this commit prevents the state of rev in the websocket loop from ever going backwards.

ready for review @kr

When compiling from today's master, I get the same issue originally reported as #32: the web view doesn't work (can't connect). When using the 0.8 packages in downloads, both 32 and 64 bit binaries give the same result on my machine:

$ doozerd
libcgo: thread-local storage 0x108 not at %gs:0x8a0 - x=0 y=0
Abort trap: 6

Almost the same result as root:

$ sudo doozerd
libcgo: thread-local storage 0x108 not at %gs:0x8a0 - x=0 y=0

And it's the same trying to use the help command:

$ doozerd --help
libcgo: thread-local storage 0x108 not at %gs:0x8a0 - x=0 y=0
Abort trap: 6

Do you need more information?

This includes a few changes:

1. General test fixes to get everything running on go1.1 (chiefly, removing explicit allocations of *net.UDPAddr.
2. server.ListenAndServe aborts on all non-temporary network errors, not just syscall.EINVAL. This was a cause of randomly hanging tests with quiet logging. When the listen socket was closed from a defer() statement in the tests, it would enter an infinite failure loop, attempting to log the error message -- which, when using ioutil.Discard, was not guaranteed to trigger the scheduler, resulting in 100% CPU usage from the serve goroutine and a hanging process.
3. Change conensensus.triggers.Less() to consider both timestamp and sequence number. The current implementation depends on undefined behaviour in container/heap which differs between go1.0.3 and go1.1.

I'd appreciate feedback on 2 and 3: though all tests pass with the changes, I could imagine consequences that aren't covered by the tests.

By default, doozerd web starts up at http://localhost:8000, But the documentation (hacking.md) was pointing it to the wrong URL (http://localhost:8080)

I followed the main README to get a feel for doozerd. The web process returns just: closed retrying in 2s [Try now]

I can get and set messages successfully:

$ doozerd -w ":8080"
$ echo "hello, world" | doozer add /message
81
$ doozer get /message
hello, world

Change the import libs package:

code.google.com/p/goprotobuf/proto ==> github.com/golang/protobuf/proto code.google.com/p/go.net/websocket ==> golang.org/x/net/websocket

Also the doc: doc/hacking.md doc/proto.md

package code.google.com/p/goprotobuf/proto: unable to detect version control system for code.google.com/ path
package code.google.com/p/go.net/websocket: unable to detect version control system for code.google.com/ path

these two libs are not hosted in code.google.com code.google.com/p/goprotobuf/proto ==> github.com/golang/protobuf/proto code.google.com/p/go.net/websocket ==> golang.org/x/net/websocket

So to change all files

import "code.google.com/p/goprotobuf/proto"  to  import "github.com/golang/protobuf/proto"
import "code.google.com/p/go.net/websocket"  to  import "golang.org/x/net/websocket"

Also: cause it import itself ha/doozerd & ha/doozer so need to change the directories ${GOPATH}/src/github.com/ha/doozer & ${GOPATH}/src/github.com/ha/doozerd all files import like above

I pulled down code... running ./all.sh I get: package github.com/ha/doozer imports code.google.com/p/goprotobuf/proto: unable to detect version control system for code.google.com/ path

I made changes in the files, replace the code.google.com with proper git hub imports in: modified: .travis.yml modified: consensus/m.pb.go modified: consensus/m_test.go modified: consensus/manager.go modified: consensus/manager_test.go modified: consensus/run.go modified: consensus/run_test.go modified: doc/hacking.md modified: doc/proto.md modified: server/conn.go modified: server/msg.pb.go modified: server/server_test.go modified: server/txn.go modified: web/web.go

I can't find any more references, but somewhere I the code is still looking for code.google.com, preventing build.

Downloaded the prepacked binary (v0.8 amd64)

executed the following commands:

doozerd
ps aux | grep doozerd
doozerd 9660 james    6u  0000     0,9        0     6343 anon_inode
doozerd 9660 james    7u  IPv6 4737813      0t0      UDP localhost:8046 
doozerd 9660 james    8u  IPv6 4737814      0t0      TCP localhost:8000 (LISTEN)
doozerd 9660 james    9r   CHR     1,9      0t0     1034 /dev/urandom

Browsed to localhost:8000/ page just constantly trys to reconnect to the events web socket. and the socket closes immediately prior to hand shaking.

Attempted to add a piece a data:

echo "hello, world" | doozer add /message

same deal. Also tried starting with doozerd -w ":8080" and browsing to 8080, same problem.

what am I missing?

Note: encountering same issue on v0.7, pretty sure I'm doing something wrong but have no clue what, lack of build instructions/requirements are also make it extremely difficult to manually build and debug.

My Node.js app is on the same machine with Doozerd.Node.js App it dynamic allocate port to bind, but when it get one free port then the doozerd service(here is account_service) bind to that port, then node.js app bind failed.