On Jan 26, 2009, at 10:31 AM, Geert Bevin wrote: > Hi Iyer, >> 1. "Nodes in the cluster topology are identified by a unique, >> persistent identity" >> >> >> How does this translate to the host-name/IP? Several TC-customers >> have had to write a map that translates the "common name" to the >> "terracotta identity" to describe the situation to others >> interacting with the cluster. It would be good if this could be >> completely avoid. >> > We haven't decided what this ID would be exactly, I was personally > thinking about the host's IP + channel ID but we should definitely > investigate to see which string is the best identifier.
Another alternative is to make the ID simple but allow some way to lookup metadata related to the ID (such as IP, hostname, a user- specified node name, or whatever makes sense). >> 2. Another problem several customers have had to solve is >> identifying a delta between a "specification of expected cluster >> Topology" and "current cluster Topology". >> e.g. I expect the following 10IPs to be present in the cluster. Any >> delta vis-à-vis the topology requires some programmatic action. Is >> there any treatment to make that easy... >> > We initially wanted to send along the whole cluster topology with each > event, and I still think that this might make the life of customers > easier. They wouldn't have to try to determine what the difference is > between the current cluster state and the cluster state at the event > time. In the latest version of the spec, we don't send the cluster > topology state along with the events anymore. Do you think that we > should? Again, this kind of sounds like a need for accessing configuration information that would tell you the expected cluster state? >> 3. >> "Clients need to change behavior when the cluster is no longer able >> to service operations: >> (a) Kill themselves >> (b) Resume ongoing operations locally by for example switching from >> a clustered cache to hitting the >> database directly >> " >> What would it take to an additional outcome of reconnecting to the >> cluster a possibility upon cluster service operations resumption. >> (with presumably state initialized to current L2 state). > I'm sorry, I'm having trouble to compute this sentence. Would you mind > rephrasing it or to give more context? I'm also not totally sure what this means but I have the feeling that it's beyond the scope of what we were trying to handle. :) > > > Thanks! > > Geert > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Flytecase Band - http://flytecase.be > Music and words - http://gbevin.com > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
