cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Counter-based continuation IDs (was Re: Load-testing flowscript webapps)
Date Sun, 08 Aug 2004 06:48:49 GMT
Vadim Gritsenko wrote:

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


Yes I had the same idea that je22 container have to solve this problem 
too. The difference is that our various objects and flowscripts are put 
into single object in the session and this single object can be quite 
large. So we would need an extension that can inspect this object and do 
replication based on this replication. Doesn't sound easy and 
unfortunatly far beyond my knowledge :-(

-- 
Reinhard


Mime
View raw message