On Thu, May 27, 2010 at 02:32:42PM +0100, Guido Trotter wrote: > On Thu, May 27, 2010 at 12:13 PM, Michael Hanselmann <[email protected]> > wrote: > > 2010/5/26 Guido Trotter <[email protected]>: > >> --- a/daemons/ganeti-masterd > >> +++ b/daemons/ganeti-masterd > >> class ClientRequestWorker(workerpool.BaseWorker): > >> # pylint: disable-msg=W0221 > >> - def RunTask(self, server, request, client_address): > >> + def RunTask(self, server, message, client): > >> """Process the request. > >> > >> """ > >> […] > >> + > >> + # FIXME: send data via push :) > >> + client.connected_socket.sendall(luxi.FormatResponse(success, result) > >> + + constants.LUXI_EOM) > > > > Apart from the fact that the operator goes to the previous line: If > > the master thread still tries to read from the socket while the > > request is handled (I guess it does), and the client sends more > > requests, the replies could be intermixed as different threads will > > write their replies whenever they're ready. LUXI is a synchronous > > protocol, hence ordering is important. Is this already taken care of? > > > > True enough. Probably for the first version a lock around sending > would be enough (and not slow down anything, since it's > per-connection). > BTW while we're at it: does request/response order count in LUXI? > With the old version we would be guaranteed to have > > M1\3M2\3M3\3 leading to R1\3R2\3R3 > > With the new one we could have > > M1\3M2\3M3\3 giving R2\3R3\3R1 > > Depending on the time various requests take to process. I don't think > we use luxi in a way that matters, but just wondering.
Yes, we need to order responses in Luxi. Current client/server can support pipelining, but neither gnt-* nor masterd actually does. iustin
