Noticed the ProjectionsManager only allows a single IP to be passed into the constructor whereas the EventStoreConnect has an overloaded Create method which takes ClusterSettings as one of it’s parameters. What’s the recommended approach here? Would gossip from a single node take care of projection changes being propagated out to the cluster?
This is correct we should support exposing the gossip information so
you know which to choose. ProjectionsManager is really just a wrapper
around some http requests.
On a side note even the gossip information may not be good enough
depending on NAT etc configuration.
This is correct we should support exposing the gossip information so
you know which to choose.
Just set up an experiment where the ProjectionManager was run individually against each of the nodes in the cluster and created unique projections across each. Regardless which node the original write occurred to (master or slaves), the unique projection ended up being created on all nodes in the cluster. What different action could be taken if gossip information were known rather than just arbitrarily writing to one of the nodes?