On 10/30/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > On 10/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > Simon Laws wrote: > > > > On 10/30/07, ant elder < [EMAIL PROTECTED]> wrote: > > > > > > > >> On 10/30/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > >> > > > >>> > > > >>> On 10/30/07, ant elder < [EMAIL PROTECTED]> wrote: > > > >>> > > > >>>> On 10/30/07, ant elder <[EMAIL PROTECTED]> wrote: > > > >>>> > > > >>>>> > > > >>>>> On 10/30/07, Simon Laws <[EMAIL PROTECTED] > wrote: > > > >>>>> > > > >>>>>> On 10/30/07, ant elder < [EMAIL PROTECTED]> wrote: > > > >>>>>> > > > >>>>>>> If you've an SCANode that is already running (you've added > > > >>>>>>> > > > >>>> composites > > > >>>> > > > >>>>>> and > > > >>>>>> > > > >>>>>>> started the node) and then you add additional composites there > > > > > >>>>>>> > > > >>>> doesn't > > > >>>> > > > >>>>>>> seem > > > >>>>>>> to be any way to start just those newly added composites. I > > can > > > >>>>>>> > > > >>>> call > > > >>>> > > > >>>>>>> SCANode.start and that kind of works but it starts all the > > > >>>>>>> > > > >>>> existing > > > >>>> > > > >>>>>>> already > > > >>>>>>> started composites as well so makes a bit of a mess duplicated > > > >>>>>>> > > > >>>> various > > > >>>> > > > >>>>>>> things. Is this something thats planed to be fixed or should I > > > >>>>>>> > > > >> go > > > >> > > > >>>>>> ahead > > > >>>>>> > > > >>>>>>> and > > > >>>>>>> add a way to do this? > > > >>>>>>> > > > >>>>>>> ...ant > > > >>>>>>> > > > >>>>>>> > > > >>>>>> Ant > > > >>>>>> > > > >>>>>> When we discussed the domain/node API a few weeks ago there > > was a > > > >>>>>> suggestion that we restrict to the node so that there is no > > fine > > > >>>>>> > > > >>>> grained > > > >>>> > > > >>>>>> control over starting the individual artifacts that a node is > > > >>>>>> responsible > > > >>>>>> for. So the lifecycle is: > > > >>>>>> > > > >>>>>> create node > > > >>>>>> add contributions > > > >>>>>> add composites to domain (indicate which composites are to run) > > > >>>>>> start composites > > > >>>>>> stop composites > > > >>>>>> remove contributions > > > >>>>>> destroy node > > > >>>>>> > > > >>>>>> So you spend some time configuring the node then you start it. > > > >>>>>> > > > >> There > > > >> > > > >>>>>> have > > > >>>>>> been some changes to the code recently but I believe this is > > how > > > >>>>>> > > > >> it > > > >> > > > >>>>>> works at > > > >>>>>> the moment. I'm looking at the code now to get back up to > > speed. > > > >>>>>> > > > >>>>>> This is an issue for both nodes and domain. . > > > >>>>>> > > > >>>>>> Firstly, as you say, in the case where you are just working > > with a > > > >>>>>> > > > >>>> node > > > >>>> > > > >>>>>> you > > > >>>>>> can't add a new contribution and start it once the node is > > running > > > >>>>>> without > > > >>>>>> doing a stop() to stop all the running components first and > > then a > > > >>>>>> start() > > > >>>>>> to restart everything. The benefit of this is at least it is a > > > >>>>>> > > > >>>> simple > > > >>>> > > > >>>>>> model > > > >>>>>> but there may be unintended consequences of doing this. I > > haven't > > > >>>>>> > > > >>>> tried > > > >>>> > > > >>>>>> this > > > >>>>>> yet with the new code changes but I will do shortly. > > > >>>>>> > > > >>>>>> Secondly, at the domain level we have provided a method for > > > >>>>>> > > > >> starting > > > >> > > > >>>>>> individually named composites. The intention here is that > > domain > > > >>>>>> > > > >>>> finds > > > >>>> > > > >>>>>> the > > > >>>>>> node with the named composite and starts it there. This suffers > > > >>>>>> > > > >> from > > > >> > > > >>>> the > > > >>>> > > > >>>>>> same problem that you face if a contribution has more than one > > > >>>>>> > > > >>>> composite > > > >>>> > > > >>>>>> in > > > >>>>>> it, i.e. subsequent composite start requests can target the > > same > > > >>>>>> > > > >>>> node. > > > >>>> > > > >>>>>> Again > > > >>>>>> this should still work if the domain first stops the node and > > then > > > >>>>>> starts > > > >>>>>> it. > > > >>>>>> > > > >>>>> I'm not clear if thats saying that the intended design is that > > the > > > >>>>> > > > >>>> only > > > >>>> > > > >>>>> way to add new contributions to an existing domain is by > > stopping > > > >>>>> > > > >> and > > > >> > > > >>>>> restarting, or that this is just a limitation of the > > > >>>>> > > > >> current code? > > > >> > > > >>>> Sorry typo in that, i meant node not domain, so: > > > >>>> > > > >>>> I'm not clear if thats saying that the intended design is that > > the > > > >>>> > > > >> only > > > >> > > > >>>> way > > > >>>> to add new contributions to an existing node is by stopping and > > > >>>> restarting, > > > >>>> or that this is just a limitation of the current code? > > > >>>> > > > >>>> ...ant > > > >>>> > > > >>> Yes, that's how the node is intended to work today. However this > > is a > > > >>> simplification strategy which means that we don't need to keep > > track > > > of > > > >>> > > > >> what > > > >> > > > >>> is and isn't started in a node. There is a price to pay in terms > > of > > > >>> flexibility and configuration performance. This means we may find > > that > > > >>> > > > >> this > > > >> > > > >>> isn't satisfactory and have to change so if this just doesn't work > > in > > > >>> > > > >> the > > > >> > > > >>> hot update web app case then we need to change our direction. > > > >>> > > > >>> > > > >> This seem to limiting to me and is a regression over what we had > > > >> previously, so I'd like to enhance it to support adding > > contributions > > > to a > > > >> running node. Happy to take suggestions for this but otherwise I'll > > > just > > > >> add > > > >> code to the SCANode interface. > > > >> > > > >> ...ant > > > >> > > > >> > > > > Well the conversation on the list turned into a code exercise to get > > a > > > > better view of what works and what doesn't. So I would say go ahead. > > > > > It'll > > > > give us a better view of what functions are really required rather > > than > > > just > > > > what we think are required. > > > > > > > > Simon > > > > > > > > > > > > > > My view is that the node should be as simple as possible: > > > - limited to one composite > > > - limited to the set of SCA contributions required to run the > > composite > > > - recyclable, a node can be reset to run another composite > > > > > > And then a server, a domain can be built out of many small nodes. > > > > > > We've been going through this several times already with different > > > versions of the domain+node API and implementations, but for some > > reason > > > we seem to be very quick at turning the node into a small application > > > server, running multiple composites, multiple independent > > contributions, > > > with lifecycle management for these composites and contributions, > > > in-memory wiring and re-wiring with composites coming and going etc. > > > This may be very well be a valid approach but I'd like to explore the > > > "simple single-composite node". > > > > > > How should I do this? Should I create a new SCASimpleNode or > > > SCALimitedNode to let you add the more sophisticated features you need > > > to the SCANode? or can we try to keep SCANode really simple for a > > while? > > > > > > Not sure if I completely agree with all that but I guess I can't seem > > the > > harm in having a SCASimpleNode if you want that while things are still > > evolving. And then before 1.1 we can review where things are at and > > refactor > > as appropriate. > > > > ...ant > > > The simple node approach has been working well in the case where the > domain is in charge. It presents a problem if you want to control the world > from a single node and run multiple composites that are added/started > incrementally in a single JVM. > > This is not a question about the details of the API though but about what > a node is for (which then of course dictates the API). If we feel a node is > sufficiently lightweight that we can pop one into existence when we need to > run a composite then that is good but is a different mindset from the one > that says the runtime is sufficiently heavyweight that we have to be able to > reuse it and hence load it up with many composites. > > I suspect that where we each sit in the 1 composite per node vs n > composites per node spectrum is coloured by our perception of how many > resources it takes to start a node. I have no evidence one way or the other > but I would like us to be slick enough to pop up a node when one is required > if nothing else as an aspiration to create as light a weight runtime as > possible. > > I not so concerned that there is a new method in the API now if it gets > the hot update function up and running today assuming that it doesn't break > the current function. This gives us a platform to see how it works and rejig > it as appropriate (including removing the new method if possible) over the > next week or so. > > I am toying with the idea that these contributions/composites in this > case should be managed through the domain proxy which has access to the > local node but it's not a fully formed though yet.
I'm not sure it is a perception of resource usage, the reason the current webapp distro is like this is because I've not yet been able to get it to work well any other way! This may well be due to limitations with the current SCADomain/SCANode implementations and if thats the case I'm sure we can fix them as things evolve - the more things using them the more clear better ways of doing things will become, but we need to get all these things using it working first . I don't particularly care if there's one node per contribution or multiple contributions per node as long as it works ok. ...ant
