[Bugs] [Bug 1333370] [FEAT] jbr-server handle lock/unlock fops

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1333370



--- Comment #6 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/14226 committed in master by Jeff Darcy
(jdarcy at redhat.com) 
------
commit c137f6a7389d7f760e4724f3506180f9cfc0da52
Author: Avra Sengupta <asengupt at redhat.com>
Date:   Mon May 16 14:55:54 2016 +0530

    jbr/locking: Define path for lock/unlock fops in JBR

    lock/unlock fops need to be handled differently than
    other 'regular' fops, so as to avoid chances of deadlock
    in blocking calls. This patch addresses the same in the
    following manner, with a caveat.

    1. On receiving the fop if the node is a follower, it
       performs the operation (irrespective of it being
       lock/unlock fop), and returns the result.

    2. If the node is a leader it follows the following paths
       for lock and unlock fops:

       For lock fops :
       -> It performs the fop on itself. If it is a failure, it
          sends -ve ack to the client. If it is successful, it
          dispatches the fop to the followers.
       -> On receiving responses from the followers, it checks
          for quorum (including the leader's outcome). If
          quorum is met, it sends +ve ack to the client.
       -> If quorum is not met, then it *should* issue a rollback
          to the followers, followed by the rollback on the leader.
          It should then send -ve ack to he client.

       For unlock fops:
       -> It dispatches the fop on the followers first.
       -> On receiving responses from the followers, it performs
          the fop on itself. On completion, it checks for quorum
          (including the leader's outcome). If quorum is met, it
          sends +ve ack to the client.
       -> If quorum is not met, then it *should* issue a rollback
          on itslef, followed by the rollback on the followers.
          It should then send -ve ack to he client.

    Caveat:
       -> jbr-server does not have a rollback framework yet,
          and hence this patch does not perform the rollbacks as
          discussed in the failure scenarios above. The rollback
          framework will be a different dependent patch.

    Change-Id: I26961b27cb85f324c1ffeee80e82ec082ffa4465
    BUG: 1333370
    Signed-off-by: Avra Sengupta <asengupt at redhat.com>
    Reviewed-on: http://review.gluster.org/14226
    Smoke: Gluster Build System <jenkins at build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-by: Jeff Darcy <jdarcy at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FzrbG6MBMn&a=cc_unsubscribe