cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Counter-based continuation IDs (was Re: Load-testing flowscript webapps)
Date Wed, 04 Aug 2004 19:32:43 GMT
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
> 
>> Reinhard Poetz wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> As Gianugo says, there's a long way to go before being clusterizable 
>>>> (could be easier with javaflow than with JS flow though). But we can 
>>>> start the journey ;-)
>>>
>>>
>>> What do you consider as the main blockers?
>>
>>
>> Here is Chris opinion:
>>   http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106704593729463
> 
> 
> Thank you.
> I understand Chris' explanations except the part "A proper replication 
> architecture would only propagate state changes between servers, not an 
> entire copy of a state." What does it mean?

He points out that transferring continuations as a whole in between 
servers might be too expensive due to size of all local rhino variables 
/ java beans / etc used in continuation and suggests to copy only 
objects which were modified from one continuation to another, to save a 
bandwidth.

Meaning, that if you have continuation A, which is already replicated to 
two servers, and then continue its execution and end up with 
continuation B, and during execution you have changed only variable X 
(but not Y, Z), and session attribute X1 (but not Y1, Z1) - then you 
need to copy only continuation B, variables X, and session attribute X1 
to the second server.

Somehow I feel it is really hard to do this in general case. Suppose 
that java bean X in continuation has a reference to Y. Then, during 
copying of X, you will have to recognize that Y should not be copied - 
but referenced; otherwise destination server will have two copies of 
same java bean, Y... I wonder how j2ee vendors go around this issue with 
session replication.

Vadim

Mime
View raw message