On Mon, Jan 19, 2009 at 2:32 PM, Geert Bevin <gbe...@terracottatech.com> wrote:
> 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. I think I am missing something. I was talking about JMX events, but it seems you are talking about something different: are you talking about another kind of TC events already available with Terracotta, which I don't know of? > 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? That's exactly my point: with proper TC events, I'd be able to do that with little code. Current JMX events have instead too much limitations. That's because I would need to send an event on both user-defined time (which leads me to the other point of my thoughts), and node disconnection. Consider the following timeline: 1 - A node connects. 2 - After some time, a worker starts on that node. 3 - Then, the worker is stopped. 4 - After some time, the worker starts again. 5 - Then, the worker disconnects due to a node failure. Now some considerations: * At 1, I don't want the master (on whatever node) to consider the just connected node as an available worker, because there's no worker actually started. * At 2, 3 and 4, the worker must notify the master of its connection/disconnection: this can be addressable through custom code. * 5 is the same as 3, but right now the former should be implemented with JMX events, while the latter with custom code, which is a mess. Here is what I mean when saying: user-defined events managed by the TC runtime. It's just a way to handle with the same code both "core" TC events (i.e. node disconnection) and "user" TC events (i.e. worker stopping). >> 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. I understand I may have been a bit unclear :) Let me restate with a simple example, referred again to the master/worker. A master (on whatever node) needs to know when a worker (on whatever node, even on the same node of the master) is disconnected. The worker may disconnect because it's programmatically stopped, or because of a node disconnection. In my mind, the master should be able to listen to a TC event sent on both use cases above: that is, when a worker is stopped, and when a worker dies because of node disconnection. I don't really care if it's the same event, or rather two different events: the most important thing is that both events should be sent by the TC server to the TC client where the master is. Is it clearer now? What do you think? As a side note, I'm almost always online on skype during standard working hours, my nick is sergio_bossa: feel free to ping me if you want to chat (by writing, I cannot talk here in the office) about that. 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
