Hi Sergio, Thanks a lot for taking the effort to read through the spec, it is much appreciated.
As discussed before, I don't think that this should be part of the cluster events mechanism. I totally understand your need for this, but I would prefer a dedicated TIM that allows users to easily register custom listeners and fire custom events across the cluster. One naive way to solve this could use a basic wait notify that only sends work to a joined none after the work queue has been started. There are of course other solutions for this, but I think they're quite use-case specific and should thus not be inside the core features. You earlier volunteered for such a TIM, are you still ok with this approach? Take care, Geert On 27 Jan 2009, at 20:55, Sergio Bossa wrote: > On Fri, Jan 23, 2009 at 5:23 PM, Geert Bevin <gbe...@terracottatech.com > > wrote: > >> Sergio, it would be very helpful if you could find some time to >> read through >> this and provide comments on how this relates to your work on tim- >> messaging. > > I read all the draft, and the new APIs look very promising. > I will comment on the Use Case 4, the one regarding the Master/Worker > implementation. > While the new APIs provide the basic node-joined node-left events, > they don't satisfy the following use case: > > 1. Node-A: joins. > 2. Node-A: starts a master instance (i.e. new Master()...); right now, > no routing destination is defined, because there's no other node. > 3. Node-B: joins; following your APIs, a node-joined event is fired, > and the master running on Node-A creates a routing destination towards > Node-B. > > This is IMHO wrong. > What if Node-B never starts a worker (i.e. new Worker() ...)? Work > tasks will be routed to the destination even if there actually isn't > any started worker! > The master on Node-A should have established a routing destination > *after* worker start-up, rather than on node start-up. > I think the new APIs should provide a common ground for implementing > custom, user-specified, events, fired at user-specified time, i.e., > when Node-B starts its worker. > By doing so, the use case would translate as follows: > > 1. Node-A: joins. > 2. Node-A: starts a master instance (i.e. new Master()...): master > code registers a listener for a custom event, named "WorkerConnected", > through DsoCluster. > 3. Node-B: joins, and a node-joined event is fired, but the master on > Node-A isn't interested at it. > 4. Node-B: starts a worker instance (i.e. new Worker() ...), and the > worker code sends a "WorkerConnected" event through DsoCluster. > 5. Node-A: the master establishes the routing destination towards > Node-B. > > The new APIs shouldn't obviously provide the specific listeners and > event types: just the basic interfaces and the engine for sending > custom implementations. > > That's all for me. > What do you think? > > -- > 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 -- 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
