Hi Indika, Thanks a lot for the very detailed explanation. So I believe what you mean in a nutshell is to use a map instead of a single Object field to store algorithm specific data. The key values will be known only to the algorithm implementation.
Am I correct with regard to that? In that case I can make this simple addition right away. I'm too +1 with moving AlgorithmContext to the Algorithm level. Currently LoadbalanceEndpoint simply stores the algorithm context but does not perform any processing with it. All the processing is done by the algorithm implementation. So it makes sense to keep the AlgorithmContext with the algorithm implementation class. But I don't think making this change is simple since algorithm implementations are developed against an interface. It seems the interface expects the AlgorithmContext to be stored somewhere else and passed into the algorithm when needed. Moving the algorithm context permanently into the algorithm may mean changing this interface and may be even introducing an abstract class. WDYT? Thanks Best Regards, Hiranya On Sat, Dec 20, 2008 at 10:21 AM, indika kumara <[email protected]>wrote: > Hi Hiranya > > Algorithm Context was introduced to encapsulate how and where states > related to the algorithm are kept. It hides fact that states are in > clustered configuration context or in local. In clustered environment > states are kept in configuration context whereas non- clustered > environment, those are locally kept. User of Algorithm Context > (Algorithm) can access these states using provided API without caring > above fact. > > Actually, Algorithm Context only need to local to Algorithm itself and > must remove reference from LB Endpoint as on one need to keep or need > to know other's states. So, it is needed to move Algorithm Context > into Algorithm and encourage as a best practice to use that for keep > states related to any algorithm implementation. We need to introduce > initialization method to algorithm API, so that algorithm itself can > initiate Algorithm Context as Algorithm Context needs configuration > context. > > Keeping states in the Algorithm Context - I think it is better to keep > a Map with setProperty and getProperty methods and must avoid adding > any algorithm specific thing to load balance endpoint. It is needed to > keep properties with KEYs specific to a particular algorithm > implementation (constant local to implementation – only care itself). > It is needed to keep primitive types as possible as in the map. This > is because, it is needed to supports both clustered and non-clustered > environment. In a clustered environment, you have to replicate states > and replicating primitive types are efficient. If there are many > states, then it may be better to encapsulate those into a serializable > data structure (need to support state replication needed in clustered > environment) and keep it in Map. BTW, these data structure and look up > keys must be local to particular algorithm implementations. > > Thanks > Indika > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
