NodeState is shared among nodes in the cluster (via gossip
in a gossip implementation) and cached locally in Cluster.Nodes
in order to be available to the /status endpoint.
It is nested under "cluster" in the config, and it controls cluster membership
as well as broadcasting, so I think type is more appropriate. Also, brevity.
interfaces are in broadcast.go and http implementations in messenger.go (gossip
is already in a separate package). Next changes will bring in the HTTP nodestate
implementation, and separate the http implementation into a separate package.
GossipNodeSet and GossipBroadcaster had a lot of cross dependency - I made them
the same object and had it implement all three interfaces (NodeSet, Broadcaster,
BroadcastReceiver).
I implmented an HTTPBroadcastReceiver which runs as as separate server.
BroadcastReceiver is a separate entity on the pilosa.Server object and is
started separately from broadcaster and nodeset. In the case of GossipNodeSet,
the broadcast receiver must be started before Open()ing the Nodeset, because it
doesn't actually start listening until Open() is called, but it needs the
handler set up before then.
server/server.go was heavily refactored to configure the new structs and
interfaces on the pilosa.Server object.
greatly simplifies Messenger, to the point of making it basically shell around
MessageBroker. Next stesp are to make the receiving of internal messages more
well-defined and behind an interface, remove/merge Messenger and MessageBroker,
and have the implementations of MessageBroker in separate packages.
moved into pilosa/server/server.go with minimal changes for now - had to tweak a
few things to be able to get at unexported fields. Next step will be to move the
implementations of NodeSet and MessageBroker out of the pilosa package so that
pilosa core knows nothing about them. pilosa/server will deal with any
complexities involved in setting them up.
