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
