Re: [infinispan-dev] ISPN-384 - Implementing hash distribution aware headers in Hot Rod

> > Sure, it could always be ordered. I assumed that the client would need > to do some ordering after applying the hash on a key and trying to > decide which server to send invocation too. Hence, my idea of giving > the list ordered to the client would be to make their life easier. > > Then again, while implementing detection of crashed members in Hot Rod > to update the Hot Rod topology information, I found that not providing > order guarantees could make the internals more flexible. For example, > we could maintain this topology as a map rather than a list, hence > making more efficient to discover whether a member has crashed or not. > The efficiency improvement comes from the fact that I checked for > crashed members by listening to JGroups view changes and when new > member list is smaller than the new one, checking whether any of the > nodes that is no longer part of the view is still present in the Hot > Rod topology list. Hence, this requires traversing the list which is > O(n). Forgot to add the ending :). So, if we ever wanted to keep the topology as a map, finding whether an old member is still present in the topology view would be an O(1) with Address as key. > > So, to summarise, I prefer not to mandate any order for the time > being.