Dynamic (hot) update of domain when the config changes

[ant elder <an...@gmail.com>]

On Tue, Jun 14, 2011 at 8:24 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 5:03 PM, Simon Laws <si...@googlemail.com> wrote:
>
> <snip>
>
>> I ended up finding that I was pretty comfortable about having a domain
>> on disc and then starting nodes with minimal configuration, I'd like
>> to look at working this up into a real piece of code in the shell or
>> the launcher. Anyone have any thoughts about this.
>>
>
> I've been wondering how to do a similar type of thing but in as simple
> as possible a way and so i'd quite like to avoid having to use a
> node.xml file. An alternative could be to use the file directory names
> to define what the domain/node looks like. To explore that I've added
> a new method createNode(File) to TuscanyRuntime where the File points
> to a file system directory which contains all the contributions and
> configuration. There's a test DirectoryDomainTestCase and a couple of
> test domain folders at:
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-node/src/test/resources/test-domains.
> This looks like it has some potential to me, and it could be used to
> extend the existing support for contribution folders in places like
> the webapp runtime and Tomcat deep integration.
>
>   ...ant
>

The other part of that which i'd like to get working is to be able to
update those contribution and config files while Tuscany is running
and have the changes automatically picked up without having to stop
and restart Tuscany. At one point we did have some support for that in
the Tomcat deep integration and it would be good to get that going
again.

There are two hard parts to doing that. One is how to work around the
locks Java holds on jars when it uses them in a URLClassLoader, and
the other is working out what the smallest thing to restart is to pick
up whatever has changed.

For the locking issue i think there's two things to try - either copy
the contribution to a temporary file and have that as whats actually
installed while still monitoring the original file for changes and
when the happens throw away the old copy and make a new copy.
Alternatively unzip (explode) the contribution jar/zip into a new
folder and have that folder as whats installed which is similar to how
containers like Tomcat work for webapp .war files.

For working out the smallest thing to restart i think the minimum may
be individual started composites. If there's a started composite from
an external .composite file or from a contribution thats exploded on
the file system then we can spot if the .composite file gets changed
and just restart the individual started composite. Even thats not
going to be totally perfect as it would missing restarts of things
using composites with <include> or <implementation.composite>. (maybe
it would be possible to fnd those by chasing all the pointers in
Tuscany, not sure, does any know if we maintain enough links to find
that?). Otherwise if anything else changes in a contribution i think
we'll just have to reinstall the whole thing and stop/start everything
that was using the contribution, i don't think it would be easy or
possible to work out what things might be using individual resources
like wsdl, xsd, or classes within a contribution.

Anyway, thats the type of thing I'm looking at if anyone has any
comments or thoughts.

   ...ant

Re: Dynamic (hot) update of domain when the config changes

[ant elder <an...@gmail.com>]

On Sat, Jun 18, 2011 at 9:23 AM, ant elder <an...@gmail.com> wrote:

> For working out the smallest thing to restart i think the minimum may
> be individual started composites. If there's a started composite from
> an external .composite file or from a contribution thats exploded on
> the file system then we can spot if the .composite file gets changed
> and just restart the individual started composite. Even thats not
> going to be totally perfect as it would missing restarts of things
> using composites with <include> or <implementation.composite>. (maybe
> it would be possible to fnd those by chasing all the pointers in
> Tuscany, not sure, does any know if we maintain enough links to find
> that?).

It turned out that finding all started composites that used another
composite was possible by chasing through all the includes and
implementations.composites, so I've added a new Node method so you can
restart those.

   ...ant