Thanks. You have a good observation here.
The TreeMap based cluster view implementation though is in the Service
Provider layer and not in the layer above it in GMS which is where
ViewWindow caches multiple views. The ViewWindow views are by
ServerToken and not by Peer ID. We may need to change that
implementation to a TreeMap based one with the same consistent hashing
algorithm as the one used in the service provider implementation layer
in order to maintain ordering consistency between the ClusterView ( in
the service provider impl) and the ViewWindow ( in the GMS
implementation core).
We do have to look at the cost benefit of this though.
One advatange of cached views is that we can instrument it through an
MBean and use it for diagnostic and monitoring purposes. If the treemap
approach is to avoid caching multiple views, then the view tracking
capabilities for monitoring are lost. So cost benefit is to be weighed.
Bongjae Chang wrote:
> Hi~ Shreedhar Ganapathy.
> First of all, I apologize for replying to your commentstoo late.
> /"Could you write a code snippet to do this? How will code looking
> only at index 1 know that B's position was before C assuming we have
> no notion of alphabetical or numerical ordering ? If there is a better
> way to do this we should do it."/
> -->
> ClusterView has TreeMap. Because TreeMap is SortedMap, We can have
> some ordering from key.
> Now key is SystemAdvertisement.getID()[==PeerGroup.getPeerID()].
> I was mis-taken in thinking that the keywas
> SystemAdvertisement.getName()[==ServerToken==MemberName] :-)
> But I think that we can utilize *TreeMap's ordering*. ex)If GMSMember
> hasSysAdv.getID() field, We can useFailedMember's SysAdv.getID() as
> well asFailedMemberToken[==FailedMember's SysAdv.getName()]for comparison.
> Then I think We don't need previous clustering view.
> This is just my idea. Please point out mistakes.
> --
> Bongjae Chang
>
> ----- Original Message -----
> *From:* Shreedhar Ganapathy <mailto:Shreedhar.Ganapathy_at_Sun.COM>
> *To:* dev_at_shoal.dev.java.net <mailto:dev_at_shoal.dev.java.net>
> *Sent:* Friday, February 15, 2008 8:35 AM
> *Subject:* Re: [Shoal-Dev] question about ViewWindow's views vector
>
>
>
> Bongjae Chang wrote:
>> Hi..
>> I have another question about ViewWindow's view vector(views). :-)
>> ---
>> <ViewWindow.java>
>> private int size = 100; // 100 is some default.
>> private final List<ArrayList<GMSMember>> *views* = new
>> Vector<ArrayList<GMSMember>>();
>> ---
>> I think Shoal mainly uses *views* for previous clustering view.
>> ex) default recovery selection algorithm orwhether there is
>> previous view or not
> Yes. That is correct.
>> *views* is Vector(default size is 100), so *views* can store a
>> lot of view's history.
>> My question is "why is *views* Vector? and why must views
>> storemore than two history?".
> No specific reason why its a Vector. It could be an ArrayList.
> Early on, I wanted to expose a monitoring interface which would
> allow a console to show the progression of last 100 views amonf
> other monitoring information about a group or group member such as
> failure histories, uptime, etc. This is particularly useful in
> large installations. We have not gotten around to do it.
>> And in SimpleSelectionAlgorithm(default algorithm), does previous
>> clustering view need?
>> ex) *views* vector has following members.
>> --------------
>> index | values
>> 0| (A,B,C,D) <-- previous view
>> 1| (A,C,D) <-- current view, B is failed
>> --------------
>> "C"will be selected from index 0
>> but I think "C" can be selected fromindex 1 because we can
>> already know Bwas failed.
> Could you write a code snippet to do this? How will code looking
> only at index 1 know that B's position was before C assuming we
> have no notion of alphabetical or numerical ordering ? If there is
> a better way to do this we should do it.
>> please give me advice.
>> thanks.
>> --
>> Bongjae Chang
>