• antirez's avatar
    CLIENT REPLY command implemented: ON, OFF and SKIP modes. · 86f0a2ee
    antirez authored
    Sometimes it can be useful for clients to completely disable replies
    from the Redis server. For example when the client sends fire and forget
    commands or performs a mass loading of data, or in caching contexts
    where new data is streamed constantly. In such contexts to use server
    time and bandwidth in order to send back replies to clients, which are
    going to be ignored, is a shame.
    
    Multiple mechanisms are possible to implement such a feature. For
    example it could be a feature of MULTI/EXEC, or a command prefix
    such as "NOREPLY SADD myset foo", or a different mechanism that allows
    to switch on/off requests using the CLIENT command.
    
    The MULTI/EXEC approach has the problem that transactions are not
    strictly part of the no-reply semantics, and if we want to insert a lot
    of data in a bulk way, creating a huge MULTI/EXEC transaction in the
    server memory is bad.
    
    The prefix is the best in this specific use case since it does not allow
    desynchronizations, and is pretty clear semantically. However Redis
    internals and client libraries are not prepared to handle this
    currently.
    
    So the implementation uses the CLIENT command, providing a new REPLY
    subcommand with three options:
    
        CLIENT REPLY OFF disables the replies, and does not reply itself.
        CLIENT REPLY ON re-enables the replies, replying +OK.
        CLIENT REPLY SKIP only discards the reply of the next command, and
                          like OFF does not reply anything itself.
    
    The reason to add the SKIP command is that it allows to have an easy
    way to send conceptually "single" commands that don't need a reply
    as the sum of two pipelined commands:
    
        CLIENT REPLY SKIP
        SET key value
    
    Note that CLIENT REPLY ON replies with +OK so it should be used when
    sending multiple commands that don't need a reply. However since it
    replies with +OK the client can check that the connection is still
    active and all the previous commands were received.
    
    This is currently just into Redis "unstable" so the proposal can be
    modified or abandoned based on users inputs.
    86f0a2ee
server.h 71.8 KB