> 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?
I'm talking about the clustered events we're (re)designing and that Taylor sent out the draft for. > 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). I still see this as a custom notification/messaging scheme in your application, certainly if you want to abstract actual cluster events and process-based events. If you get the cluster event that tells you that the topology changed, you can consume it and send out an event that is specific for your application. Since the POJO based API will be based on interfaces that you implement and register with a TC-injected utility object, you can use the typical Java approach of implementing several interfaces by the same listener class. This would allow you to bind both together. The cluster events we're thinking of in the light of this redesign is to provide information about the state of the cluster that is not possible to obtain otherwise. Extending this towards allowing people to register and trigger their own events through the server would imho cross the lines of the purpose of Terracotta. DSO gives you the core tools to make things possible, not necessarily with a ready-cooked implementation or interface for all use cases. We extend that functionality through TIMs that are much higher level. So the way I see it is that as long as the cluster events redesign allows a TIM to be written with higher level features, its scope is correct. There are other reasons for the latter though, for instance, we don't want to keep state about the routing and the queue of your custom messages in the server. Also, what about applications that don't need/ want this, they shouldn't need to pay any penalty for it, etc... Finally, since these features do'nt seem to be tied directly into the core of DSO itself, they don't need to be tied to its release schedule. We can push out newer versions much quicker. Those are other reasons why we try to extract these things out of the core and into TIMs as much as possible. >>> 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? Think I answered this already above :-) I suggest that I write out the detailed spec and API proposal first. If you have time, it would be awesome if you could check that the low- level features you needed for master/worker are now there to at least make it possible to implement your needs. We can then later see about maybe creating a TIM with a higher level scope. How does that sound? 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
