Hi, we are trying to set requireMaster=false when connecting to eventstore with the Java client. I was hoping this would distribute the connections among our 3 nodes in the cluster, but it looks like all connections are made to the leader node regardless. Digging into the client code, this section
final case class ClusterInfo(serverAddress: InetSocketAddress, members: List[MemberInfo]) {
lazy val bestNode: Option[MemberInfo] = {
val xs = members.filter { x => x.isAlive && x.state.isAllowedToConnect }
if (xs.isEmpty) None else Some(xs.maxBy(_.state))
}
}
it looks like .maxBy takes the node with the highest .id (leader has id=10 and follower has id=9)
we use dns for discovery.
Hi Morten,
A cluster node connection doesn’t do load balancing. What a cluster mode connection does, however, is to reconnect to another node of the cluster if the one you were already connected failed. That type of connection will do its best to meet your preference if specified. By setting requireMaster=false and don’t set any node preference, the connection will pick a node randomly (It’s still possible you end up connected to a master node though)
Thank you Yorick, I would expect to get a random node when connecting with requireMaster=false,
but ony gets master. The documentation wasn’t quite clear on this, but as I understand it setting requireMaster=false means read operations ca be executed on a slave node if that’s what you are connected to. But when all connections end up on the master node, all operations will be done there regardles.
Remember that gRPC is not a connection per se. It can only be seen as a connection when using long-living gRPC streams, basically it would be subscriptions only. All other scenarios are normal RPC calls with a limited lifecycle. Hence that’s why it’s called the Client, not Connection (at least right now).
Also, remember that write ops go through the leader node unconditionally. If your client does reads and writes, it will have to connect to the leader. If you only reads, you can rather use PreferFollower (or how it’s called in the Java client).
I might be wrong @alexey.zimarev but I think @morten.aasnes is using the JVM TCP client that is written in Scala: https://github.com/EventStore/EventStore.JVM
requiresMaster doesn’t exist in gRPC clients as we renamed Master to Leader and Slave to Follower
We use the Scale/Akka client yes (in a Java project)
I don’t think it uses gRPC. At least all connections are visible on the Eventstore Dashboard (on the leader node). The follower nodes only has the internal connections.
Right, my bad 
Should’ve noticed it from the master/slave terminology, which is gone in all the new clients.
Still, my experience with the .NET TCP client was similar. I even had a situation when I explicitly set PreferSlave on one connection and not on another, but they were in the same app, then both were connecting to slave nodes. If I only have one connection, wich is only used for subscriptions, then PreferSlave worked as expected.