Hi,
Some of these questions came up after reading the thread on totem. However I started the new thread so that searching is easy and also want distract the intense discussions on totem with out-of-topic questions.
Jules Gosnel wrote
>This is not something that is really considered a significant saving in
>WADI (see my last posting's explanation of why you only want one
>'active' copy of a session). WADI will keep session backups serialised,
>to save resources being constantly expended deserialising session
>backups that may never be accessed. I guess actually, you could consider
>that WADI will do a lazy deserialisation in the case that you have
>outlined, as primary and secondary copies will actually swap roles with
>attendant serialisation/passivation and deserialisation/activation
>coordinated by messages.
>If you are running a reasonable sized cluster ( e.g. 30 nodes - it's all
>relative) with a small number of backups configured (e.g. 1), then, in
>the case of a session affinity brekdown (due to the leaving of a
>primary's node), you have a 1/30 chance that the request will hit the
>primary, a 1/30 that you will hit the secondary and a 28/30 that you
>will miss :-) So, you are right :-)
>WADI (see my last posting's explanation of why you only want one
>'active' copy of a session). WADI will keep session backups serialised,
>to save resources being constantly expended deserialising session
>backups that may never be accessed. I guess actually, you could consider
>that WADI will do a lazy deserialisation in the case that you have
>outlined, as primary and secondary copies will actually swap roles with
>attendant serialisation/passivation and deserialisation/activation
>coordinated by messages.
>If you are running a reasonable sized cluster ( e.g. 30 nodes - it's all
>relative) with a small number of backups configured (e.g. 1), then, in
>the case of a session affinity brekdown (due to the leaving of a
>primary's node), you have a 1/30 chance that the request will hit the
>primary, a 1/30 that you will hit the secondary and a 28/30 that you
>will miss :-) So, you are right :-)
So just to figure out if I understand this correctly.
1.) WADI only has one active and one-two backups at most (I assume the no of backups is configurable)
2.) WADI is built up on the assumption of session affinity. So the probability of missing the primary and the secondary backup(s) goes up as the cluster grows according to your example
3.) How does WADI handle a situation where there is no session affinity??
4.) Have you compared the overhead of maintaining session affinity vs having R replicas (all-Active) to service the client.
>If, however, you did your deserialisation of replicants up front and thus avoided further messages when a secondary was hit, by maintaining
>all copies 'active' (I think you would not be spec compliant if you did this),
>all copies 'active' (I think you would not be spec compliant if you did this),
1.) What do u mean by spec here ?? Are u talking about the WADI spec?
2.) Assuming sombody wants to do session replication (All Active) instead of (one Active and "n" backups) is there provision within the WADI api to plug in this stratergy?
If u remeber we talked about extention points within WADI.
1.) Is there a doc that describes WADI architecture
2.) Is there a doc that describes these extention points and how to do it?? (Looking for a little more info than the API doc)
Thanks,
Rajith.
