Andrey, Huge +1 for that. "Force server mode" increases the complexity of understanding how cluster in ring mode works without real benefits. If a user wants to start client node first before server nodes have started, he can adjust timeouts on connection and spin till a client is connected. Ability to join client node to topology without server nodes looks dubious. As we have thin clients and Zookeeper Discovery SPI this mode looks like a crutch and should be removed.
2018-08-09 12:41 GMT+03:00 Andrey Mashenkov <[email protected]>: > Hi Igniters, > > I've found that KernalContext.clientNode() and TcpDusciveryNode.isClient() > means different and it looks confusing. > > 1. The first one return true if "node is configured as client" and false > otherwise, > 2. The second one can return false if server mode is forced for client (via > TcpDiscoverySpi.setForceServerMode(true)) , > so actually true value means "a client node is out of the ring". > > Thus, TcpDiscoveryNode.isClient() semantic is broken and we can get > confusing results on client node with forced server mode, > when kernalContext.clientNode() return true and > kernalContex.localNode().isClient() return false. > > Also, we have a number of places in code where node.isClient() method is > used. > > My suggestion is > 1. Deprecate force server mode and plan to remove it to next major release. > 2. Fix TcpDiscoveryNode,isClient() semantic e.g. to use node attributes to > make ClusterNode.isClient method consistent with node configuration. > 2. Add isRingNode (possibly package private) with current > TcpDiscoveryNode.isClient() semantic to preserve compatibility. > > Any pros or cons? > > -- > Best regards, > Andrey V. Mashenkov >
