On 10/30/07, Simon Laws <[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. > > > > Simon > > > > I have found a snag with the starting/stopping approach which I'm just > fixing now. I'll check in a fix shortly. > > Simon >
I just put a fix in to stop the node forgetting everything it knows about configured contributions when it is stopped. If you need to remove contributions you can do that by contribution name. If you really need to blow away a node you can destroy it and create a new one. In this way the node can be started and stopped as required. Simon
