server: add a comment explaining the call redirect logic in ctdb_call_send_redirect().

diff --git a/server/ctdb_call.c b/server/ctdb_call.c
index c8729ce1c11d39782807da45c81f3c82535cf266..73072c3f758529b45bc2c0adf2bd6434927a66df 100644 (file)
--- a/server/ctdb_call.c
+++ b/server/ctdb_call.c
@@ -99,9 +99,30 @@ static void ctdb_send_error(struct ctdb_context *ctdb,
 }
 
 
-/*
-  send a redirect reply
-*/
+/**
+ * send a redirect reply
+ *
+ * The logic behind this function is this:
+ *
+ * A client wants to grab a record and sends a CTDB_REQ_CALL packet
+ * to its local ctdb (ctdb_request_call). If the node is not itself
+ * the record's DMASTER, it first redirects the packet to  the
+ * record's LMASTER. The LMASTER then redirects the call packet to
+ * the current DMASTER. But there is a race: The record may have
+ * been migrated off the DMASTER while the redirected packet is
+ * on the wire (or in the local queue). So in case the record has
+ * migrated off the new destinaton of the call packet, instead of
+ * going back to the LMASTER to get the new DMASTER, we try to
+ * reduce rountrips by fist chasing the record a couple of times
+ * before giving up the direct chase and finally going back to the
+ * LMASTER (again). Note that this works because auf this: When
+ * a record is migrated off a node, then the new DMASTER is stored
+ * in the record's copy on the former DMASTER.
+ *
+ * The maxiumum number of attempts for direct chase to make before
+ * going back to the LMASTER is configurable by the tunable
+ * "MaxRedirectCount".
+ */
 static void ctdb_call_send_redirect(struct ctdb_context *ctdb, 
                                    TDB_DATA key,
                                    struct ctdb_req_call *c,