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

[Manik Surtani]

<SNIP />

>> 
>> 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.

Yup, hence my thoughts on not mandating order.  :)

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org