bossadvisors / memcached-session-manager

Automatically exported from code.google.com/p/memcached-session-manager
0 stars 0 forks source link

Backup of a session should take place on the next available node when the next logical node is unavailable. #113

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
I configured 3 nodes A,B,C.I then made a request and received a session having 
an id A (this should have been backed up on B).I then turned off node B and 
made a request.I received a session with an id A .Thinking that this would now 
be backed up on node C I turned off node A.I got logged off and the session 
since was not backed up on node C.

What is the expected output?
During a conversation you had mentioned that the backup takes places on the 
next logical node and if the node is down it would get backed up on the next 
available node.Hence it should have been backed up on node C.

What do you see instead?
I got logged off and the session was not backed up on node C.

What version of the product are you using? On what operating system?
memcached-session-manager-1.5.1 on Red Hat Enterprise Linux Server release 5.5.

Please provide any additional information below.
Running this with sticky="false".

Original issue reported on code.google.com by reinw...@gmail.com on 3 Nov 2011 at 3:51

GoogleCodeExporter commented 9 years ago

Original comment by martin.grotzke on 4 Nov 2011 at 10:26

GoogleCodeExporter commented 9 years ago
Fixed/implemented.

Secondary backup is now written/read from the next available node. The 
consequence is that for the improved availability the consistency is reduced:
* if a session stored in A got its backup in B
* then there's a network partition so that B is unavailable so that the backup 
is stored in C
* B is available again (network partition resolved)
* A is not available, session is loaded from B
-> potentially outdated data is read from B

Potential solutions:
* somewhere (e.g. in the validity info) store where the last backup was stored 
(would increase costs related to secondary backup)
* let the user choose between availability and consistency

The current implementation can be improved, submitted issue #117 for this.

Original comment by martin.grotzke on 26 Dec 2011 at 11:04