Hi Geert, > 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? 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 ;) > 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? >> 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. > Thanks, we'll send out the API suggestion when it starts taking shape. Great, I can't wait for them ;) Cheers, Sergio B. -- Sergio Bossa Software Passionate, Java Technologies Specialist and Open Source Enthusiast. Blog : http://sbtourist.blogspot.com Sourcesense - making sense of Open Source : http://www.sourcesense.com Pro-netics s.p.a. : http://www.pronetics.it _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
