On blocks reload (Re: [RT] On building on stone)

[Pier Fumagalli <pi...@betaversion.org>]

On 26 Mar 2004, at 17:46, Pier Fumagalli wrote:

> That's ALL _IMVHO_, I don't know what others think, but we mustn't 
> forget that our container needs to solve one very very very specific 
> problem, the Cocoon problem...

Hmm... Thought about it over some nicotine, and if people do really 
feel strong about not loosing component instances "all of a sudden", 
I'd rather go down the path the JVM uses: garbage collection.

When a block is "reloaded" (because of an update of its classes, or a 
change in its configuration), simply its instance remains available in 
the container, but "inactive".

All new lookups will happen on the new block instances, previously 
acquired components will still work with the old block, no question 
asked (never loose anything).

And then to have a some sort of "Garbage Collector" which flushes out 
all previously deployed block instances not having components instances 
wired from other blocks.

Only thing I can think about is that some block might never be garbage 
collected because someone didn't release a wiring, but probably we can 
"force" a manual disconnection (notify the admin who triggered the 
reload, or something).

	Pier

Re: On blocks reload (Re: [RT] On building on stone)

[Sylvain Wallez <sy...@apache.org>]

Pier Fumagalli wrote:

> On 26 Mar 2004, at 17:46, Pier Fumagalli wrote:
>
>> That's ALL _IMVHO_, I don't know what others think, but we mustn't 
>> forget that our container needs to solve one very very very specific 
>> problem, the Cocoon problem...
>
>
> Hmm... Thought about it over some nicotine, and if people do really 
> feel strong about not loosing component instances "all of a sudden", 
> I'd rather go down the path the JVM uses: garbage collection.
>
> When a block is "reloaded" (because of an update of its classes, or a 
> change in its configuration), simply its instance remains available in 
> the container, but "inactive".
>
> All new lookups will happen on the new block instances, previously 
> acquired components will still work with the old block, no question 
> asked (never loose anything).
>
> And then to have a some sort of "Garbage Collector" which flushes out 
> all previously deployed block instances not having components 
> instances wired from other blocks.


+1. I was about to propose exactly this, as we don't need to handle 
non-existing blocks as in the case of distributed systems. Blocks 
dependencies will always be satisfied, it just that "who" satifies it 
changes over time. So when a component is looked up, it's used until 
released, even if its originating block has been replaced by another one 
inbetween.

Something that has to be considered, though, is if the whole wire (i.e. 
all used components) between two blocks changes at once, or if traffic 
progressively switched from the old wire to the new one (i.e. lookup in 
the new block even if some components of the old one are still being 
used). The first solution avoids any consistency problems, but at the 
same time can prevent the actual wire switch to occur,  especially under 
load, where there will be a permanent traffic over the old wire, 
preventing the switch to the new one.

> Only thing I can think about is that some block might never be garbage 
> collected because someone didn't release a wiring, but probably we can 
> "force" a manual disconnection (notify the admin who triggered the 
> reload, or something).


Yep.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: On blocks reload (Re: [RT] On building on stone)

[Torsten Curdt <tc...@vafer.org>]

>> That's ALL _IMVHO_, I don't know what others think, but we mustn't 
>> forget that our container needs to solve one very very very specific 
>> problem, the Cocoon problem...
> 
> 
> Hmm... Thought about it over some nicotine, and if people do really feel 
> strong about not loosing component instances "all of a sudden", I'd 
> rather go down the path the JVM uses: garbage collection.
> 
> When a block is "reloaded" (because of an update of its classes, or a 
> change in its configuration), simply its instance remains available in 
> the container, but "inactive".
> 
> All new lookups will happen on the new block instances, previously 
> acquired components will still work with the old block, no question 
> asked (never loose anything).
> 
> And then to have a some sort of "Garbage Collector" which flushes out 
> all previously deployed block instances not having components instances 
> wired from other blocks.
> 
> Only thing I can think about is that some block might never be garbage 
> collected because someone didn't release a wiring, but probably we can 
> "force" a manual disconnection (notify the admin who triggered the 
> reload, or something).

sounds great to me +1
--
Torsten

RE: On blocks reload (Re: [RT] On building on stone)

[Leo Sutic <le...@inspireinfrastructure.com>]

Pier,

I'd actually rather see you just axed the block with no
further ado.

Having a stale reference to a component may just make the 
bugs more subtle and harder to find.

/LS

> From: Pier Fumagalli [mailto:pier@betaversion.org]