There are two concepts here.
As far as the cluster is concerned, there is one coordinator node which manages the cluster view. You should read http://jgroups.org/manual/index.html#DiscoveryProtocols to help you understand the concepts there, but the cluster coordinator has nothing to do with the distribution and ownership of the data.
Entries in the caches are assigned to nodes according to their consistent hash. The hash space is divided into segments and each segment is assigned to a node in the cluster. A node will therefore "own" multiple segments (the number of segments is configurable). Therefore the segment an entry is assigned to determines its primary owner. Backup owners (i.e. the copies of that entry, whose count is numOwners-1), are chosen among the segments belonging to other nodes to ensure that no physical node owns more than one copy of the data. As nodes leave/join, segments are moved around (rebalancing), maintaining the above conditions. If, for performance reasons, you want to ensure that two or more entries are owned by the same node, you should consider using grouping.
The HotRod protocol is clever, in that it knows the hashing algorithm and the segment ownership, and so it will directly go to the primary owner, without additional hops.
Okay, so client code does not have to worry about that, hotrod client runtime smartly routes the request to the primary owner, given the address of any node which belongs to the cluster, right??