Hi Sergio, Thanks for your comments.
>> Isn't that something that you can handle by keeping track of the >> different states yourself? > > Not so easily. > Take the dynamic master/worker implementation as an example: masters > need to know when a worker disconnects from the cluster due to a node > failure, how to do that without a proper event managed by the TC > runtime? You would get a "topology changed" event with the current cluster topology as a data element. You then compare that with a master/worker- specific clustered data structure that keeps track of which nodes are masters and which ones are workers. If the node simply disconnects because a connection is temporarily severed, you would get an "operations disabled" event. There's thus a clear difference between both now. Maybe I'm missing something though, but it seems to me that with a small amount of coding you could get want you need. If not, can you please tell me what the problems would be since I don't know the internals of the master/worker implementation? > Right now, given that I recently removed JMX events from the > implementation, I'm using a queue-based keep-alive mechanism, but > using a TC event would make the whole stuff easier and probably more > efficient. > And I have to say I can't wait to add the master/worker implementation > based on the new TC events, as soon as they will be available ;) Cool! We need use cases :-) >> We were also >> thinking of always sending around the entire cluster topology data >> along with each event. This would make it easy to know the cluster >> state at the moment that the event was sent, without risking to base >> logic on an outdated cluster state. > > A better approach may be to use some kind of annotation-based > dependency injection: that is, inject into TC-managed objects a > "ClusterTopology" object containing information about the current > cluster state: what do you think? We discussed that, the problem is that this is then dissociated from the event and that there's always a possibility of that field not corresponding to an event that's being processed. Since topology changes events are supposed to be rare, the additional overhead of sending the node IDs in the cluster along with the node types would be neglectable. This seemed like the simplest approach. >>> That is, it would be great to be able to send and receive >>> notifications of user defined events during node lifecycle, i.e.: >>> sending a user defined event when a node leaves the cluster. >>> What do you think? >> >> It might be interesting to design something like that but I'm >> wondering if this should be part of the core cluster events. It seems >> to me that this could be a forge project that consumed the cluster >> events and sets up a messaging channel for the user events. I >> personally prefer to keep the core functionalities as focused as >> possible, as long as of course all other required features can be >> implemented as a TIM. > > I agree with you: the smallest the core functionalities are, the > better it is. > However, I think that the messaging channel you are talking about > should be managed by the TC runtime: that is, you should be able to > set-up user defined events even for the node lifecycle bounds, i.e. > node connection and disconnection. Would you mind providing a bit more detail about how you would see this work? Maybe some snippets of pseudo code to illustrate the usage for some of your specific problems. Thanks! Take care, 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
