ant elder wrote:
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
My 2c... It'll be easier to get something clean and working ok if we
keep the node as simple as possible for now and don't try to boil the
ocean right away with multiple composites and complex lifecycle and
update management. I'll create a new SCASimpleNode as you suggested to
explore the 1-composite-per-node basic approach.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
