Added timeout goroutine to stop waiting on lock after timeout
expiration.
This necessitated reworking the flow of the acquire handler. createNode
now _only_ creates the node; it no longer waits on the lock itself.
getLockIndex (perhaps this is poorly named) extracts out the lock
checking routine so that it can be used by "get" and "watch", both.
get() was added to instantaneously attempt to acquire a lock with no
waiting.
If a lock fails to acquire, for whatever reason, an error is returned,
resulting in a code 500 to the client.
The waitIndex was being pulled from the wrong node in the lock parent which caused the watch to be returned immediately. This caused a continuous set of calls while a client was waiting for a lock.
for i in github.com/BurntSushi/toml github.com/coreos/go-etcd/etcd github.com/coreos/go-log/log github.com/gorilla/context github.com/rcrowley/go-metrics bitbucket.org/kardianos/osext github.com/coreos/go-systemd/journal github.com/coreos/raft code.google.com/p/goprotobuf/proto ; do goven -copy -rewrite $i; done
ModifiedIndex in the lock directory is not incremented and the event
store has only 1000 histories for now.
Acquiring a lock is not queued while (index - ModifiedIndex) > 1000 and
prevIndex exists.
If closeChan is available and stopWatchChan was closed by defer
select selects a single channel randomly. This causes a panic sending to closed
channel.
