cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [RT] On building on stone
Date Fri, 26 Mar 2004 17:46:44 GMT
On 26 Mar 2004, at 14:44, Leo Sutic wrote:
>> From: Pier Fumagalli [mailto:pier@betaversion.org]
>>
>> On 26 Mar 2004, at 11:57, Leo Sutic wrote:
>>>
>>> Think about TCP/IP. You have guaranteed delivery of packets
>> (which you
>>> don't have with UDP). Completely guaranteed? No. A
>> chopped-off network
>>> cable is not something that the protocol can handle. But still very
>>> useful.
>>
>> The TCP/IP is a good example...
>>
>> To use the same parallel, when I open a TCP connection I am guaranteed
>
>> that I'm going to get a Socket object (to use Java) I can use. But the
>
>> platform doesn't guarantee me that its InputStream or OutputStream are
>
>> going to be valid forever, they might throw IOExceptions, and the
>> socket itself can be in a connected or disconnected status (you're
>> never guaranteed).
>>
>> You go usually until you don't hit an IOException on the streams (or
>> isConnected() returns true), but then you'll have (somehow) to handle
>> that state change which you don't control...
>>
>> Wirings between blocks behave in the same way, you go until one of the
>
>> methods you call doesn't return an exception, or until the wiring is
>> available (err, you can check on that),
>
> Actually, you can't.
>
> There's no guarantee that the block isn't going to be swapped out
> between the checking call and the next method call.
>
> So there's absolutely no point in making the checking call.
>
> There's even no guarantee that the block won't be swapped out ***while
> it
> is executing a method***.
>
> Now that's starting to become dangerous.

Why? If a request fails because I reloaded the XSLT Transformer block, 
well, I'm ready to loose that request... Cocoon is a servlet, at the 
end of the day, and I'd rather loose XSLT translation for 1/2 a second 
while I reload the XALAN block, than wait 10 minutes while I reload the 
JVM, as I can't reload XSLT because every single Pipeline in my sitemap 
is locking on it, and (of course) I will never ever be able to reload 
it until the traffic on my website goes down to ZERO...

Dude, don't get upset, I'm not thinking about the holy grail here, I 
_DO_NOT_WANT_ to write another Avalon, I want Cocoon to have a 
container tailored EXACTLY for its own requirements, being a servlet 
and all...

Let's not forget that we work on HTTP connections, and that at any 
given point in time, those can be disconnected, time out, or your 
network admin can unplug the cable...

What's the difference between that, and loosing the connection for a 
second with a component? Thing, that (by the way) will _NEVER_ happen 
automagically, but only when the administrator decides that it's time 
to reload a block instance?

Instead, the difference between having to shut down a VM because you 
need to reload a component (and loosing ALL your requests, but also all 
your continuations, sessions, you name it), and unwiring a component 
(and loosing ONLY the requests that were using that component), is for 
Cocoon quite a friggin' advantage.

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...

	Pier

Mime
View raw message