question history:
question 
87 views

SERVER_WRITE_LOCK under different conditions

Hi,

I wanted to know about the conditions with which we set the SERVER_WRITE_LOCK as I feel it's a bit ambiguous in the spec.

When a new server is being added, we need to initiate data transfer from some older server and the newer one. In this situation, it's clear that the older server should be in WRITE_LOCK, but what about the new server? (I realize connections to new server probably cannot be made since the metadata is not known until data transfer is complete, so this may just be an undefined case which does not matter).

Similarly, in the case where a server is being deleted (server A) and it's data is being transferred to another (server B), in this situation will both be locked under WRITE_LOCK? Again, it's clear to me that the server being deleted should have WRITE_LOCK on it, but what about server B?

Thank you

 0
Updated by Anonymous Gear

the students' answer,

where students collectively construct a single answer

I realize connections to new server probably cannot be made since the metadata is not known until data transfer is complete, so this may just be an undefined case which does not matter.

This is case is defined.  In fact, it's specified on the M2 handout:

Once the KVServer launched, it is in the state stopped. That means it is able to accept client connections but will answer with SERVER_STOPPED. Then. the KVServer connects to ECS to retrieve the metadata.

 1
Updated by Anonymous Poet

the instructors' answer,

where instructors collectively construct a single answer

Hi,

Server B would also be in SERVER_WRITE_LOCK until the data hand-off is completed. Imagine a scenario where a key K1 is present in Server A but it is not yet transferred to Server B. A client sends a KV pair to Server B with K1. Server B would respond with PUT_SUCCESS instead of PUT_UPDATE.

 1
Updated by Jawad Tahir
followup discussionsfor lingering questions and comments
Anonymous Poet 

Screen_Shot_2023-02-28_at_1.11.09_AM.png

I don't think that should be the behavior under the described scenario.  During the hand-off / rebalance period, when a client sends a KV pair to Server B with K1, Server B should not respond with PUT_SUCCESS nor PUT_UPDATE, instead it should forward the request to Server A, at which point Server A responds with a SERVER_WRITE_LOCK.  As far as I can see, during the hand-off / rebalance period, Server B is safe to serve both read and write requests for its keyrange since there's no overlap between the Server A and Server B keyranges. Remember, Server B's metadata doesn't get updated until the hand-off is completed.

 0
Jawad Tahir

KVServers do not forward requests. If a server is not responsible for a key, it will respond with SERVER_NOT_RESPONSIBLE command. The client then sends the command to the appropriate server after updating the meta data.

 0
Anonymous Poet

Okay, KVServers don't forward requests.  My point was that Server B should not respond with PUT_SUCCESS nor PUT_UPDATE in the said scenario.

In that case, the client would retry the request by sending it to Server A, at which point Server A responds with a SERVER_WRITE_LOCK.

Again, as far as I can see, during the hand-off / rebalance period, Server B is safe to serve both read and write requests for its keyrange since there's no overlap between the Server A and Server B keyranges. Remember, Server B's metadata doesn't get updated until the hand-off is completed.

What am I missing?

 1
Michalis Bachras

What I would do is process read requests on server A until the handoff is completed, suspend at the same time incoming write requests and after the completion of the handoff, remove the transferred data.

 0