> 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).
Sounds like a good idea! This could even be included as additional methods on the DsoNode class and the information can be cached locally. >>> 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? The problem here is "expected"? Would this be the cluster state at the time of the event trigger? Making sure that this is accessible without including it in the event would require some kind of repository of cluster states that people can query to find out which one corresponds to an event. Then we get also into the whole problem of having to maintain that. Including it with an event seems much simpler imho. It wouldn't need to be large at all, this cluster state can internally be send using a simple number for each node and send an array of shorts around (a max of 65k nodes seems sufficient ;-)). This could then locally be expanded to actual node IDs. -- 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
