1) I propose that the node id should be completely opaque. I don't like making it something people will depend on, as it is then a part of the API (at least implicitly)
2) Providing a method to obtain the cluster information Iyer has asked for makes a lot of sense. I am not sure this is in scope for this effort, but I would entertain it presuming the LOE is not too great (and Steve agrees). In fact Gary Keim and discussed at some point introducing a capability for naming clients just as servers can be named. I don't think we should introduce this particular feature just yet, but I think that by introducing an API and some sort of "cluster node meta information" class, we could encapsulate the known data about a particular cluster node and modify it in the future to include such a feature. 3) After several discussions concering delivering state w/ the event vs. state as an API and not w/the event, I am firmly on the side of state as an API. My reasoning is thus: a) The state that comes with the event is guaranteed to be stale by the time of the delivery b) The state that comes from an API is guaranteed to be stale by the time it is returned to the user Therefore, a and b are not much different from one another in terms of stale or not stale, but a) is a lot more expensive to implement, and may simultaneously not be used by the end user. The programming paradigm for querying after receipt of the event is exactly the same as when programming a wait() event loop. When wait is woken by a notify, you must always check the state of the system (which is why a wait must always be surrounded by a while). The same will be true for receiving events from the cluster - they will only notify you that something has changed, but due to the fact that a cluster is dynamic, you must query the cluster for its state and react appropriately. ----- Original Message ----- From: "Geert Bevin" <gbe...@terracottatech.com> To: tc-dev@lists.terracotta.org Sent: Monday, January 26, 2009 9:40:53 AM GMT -08:00 US/Canada Pacific Subject: Re: [tc-dev] First public draft of new cluster events design > 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
_______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
