[Gluster-devel] Gap in protocol client-server handshake

Avra Sengupta asengupt at redhat.com
Mon Feb 29 11:50:53 UTC 2016


Hi,

Currently on a successful connection between protocol server and client, 
the protocol client initiates a CHILD_UP event in the client stack. At 
this point in time, only the connection between server and client is 
established, and there is no guarantee that the server side stack is 
ready to serve requests. It works fine now, as most server side 
translators are not dependent on any other factors, before being able to 
serve requests today and hence they are up by the time the client stack 
translators receive the CHILD_UP (initiated by client handshake).

The gap here is exposed when certain server side translators like 
NSR-Server for example, have a couple of protocol clients as their 
child(connecting them to other bricks), and they can't really serve 
requests till a quorum of their children are up. Hence these translators 
*should* defer sending CHILD_UP till they have enough children up, and 
the same CHILD_UP event needs to be propagated to the client stack 
translators.

I have sent a patch(http://review.gluster.org/#/c/13549/) addressing 
this, where we maintain a child_up variable in both the protocol client 
and protocol server translators. The protocol server updates this value 
based on the CHILD_UP and CHILD_DOWN events it receives from the 
translators below it. On receiving such an event it forwards that event 
to the client. The protocol client on receiving such an event forwards 
it up the client stack, thereby letting the client translators correctly 
know that the server is up and ready to serve.

The clients connecting later(long after a server has initialized and 
processed it's CHILD_UP events), receive a child_up status as part of 
the handshake, and based on the status of the server's child_up, either 
propagate a CHILD_UP event or defer it.

Please have a look at the patch, and kindly state if it you have any 
concerns or you foresee any scenarios of interest which we might have 
missed.

Regards,
Avra



More information about the Gluster-devel mailing list