Description of problem: When lock-heal is enabled for a volume, grace_timer is registered during disconnect received by client translator after a portmap query. This was discovered in client logs as follows. . . . [2015-09-10 10:47:41.114371] D [MSGID: 0] [client.c:2027:client_rpc_notify] 0-vol-client-0: got RPC_CLNT_DISCONNECT [2015-09-10 10:47:41.114446] I [MSGID: 114004] [client.c:197:client_register_grace_timer] 0-vol-client-0: Registering a grace timer . . . And this grace_timer is cancelled immediately following the connect to glusterfsd. [2015-09-10 10:47:41.121995] D [MSGID: 0] [client.c:1987:client_rpc_notify] 0-vol-client-0: got RPC_CLNT_CONNECT . . . [2015-09-10 10:47:41.122688] W [MSGID: 114005] [client.c:2014:client_rpc_notify] 0-vol-client-0: Cancelling the grace timer . . . Version-Release number of selected component (if applicable): master How reproducible: 100% Steps to Reproduce: 1. Create a 1-brick volume. 2. Set client log level to DEBUG gluster volume set <VOLNAME> client-log-level DEBUG 3. Enable lock-healing gluster volume set <VOLNAME> lock-heal on 4. Mount the volume. 5. Check mount log for the above mentioned entries. Actual results: grace_timer was registered. Expected results: grace_timer should not be registered.
REVIEW: http://review.gluster.org/12152 (protocol/client: Do not register grace_timer for disconnect to glusterd) posted (#1) for review on master by Anoop C S (anoopcs)
REVIEW: http://review.gluster.org/12152 (protocol/client: Do not register grace_timer for disconnect to glusterd) posted (#2) for review on master by Anoop C S (anoopcs)
The grace_timer logic is being removed from protocol client and server. Follow https://bugzilla.redhat.com/show_bug.cgi?id=1272030 for further details.