Bug 1158746

Summary:	client process will hang if server is started to send the request before completing connection establishment.
Product:	[Community] GlusterFS	Reporter:	Mohammed Rafi KC <rkavunga>
Component:	rdma	Assignee:	Mohammed Rafi KC <rkavunga>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	anoopcs, bugs, gluster-bugs, jthottan, kkeithle, rtalur
Target Milestone:	---	Keywords:	Patch, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.7.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-05-14 17:28:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mohammed Rafi KC 2014-10-30 05:36:54 UTC

Description of problem:

When using rdma protocol, client and server will interchange their available buffers during the handshake to post incoming messages. Initially the available buffer is set to one for the first message during handshake,when first message is received, available quota for the buffer will set to proper value. So before receiving the message if server started to send the message, then the reserved buffer for handshake will be utilised, then the handshake will fail because of lack of buffers. So we should block sending messages by server before proper connection establishment.

Version-Release number of selected component (if applicable):

All

How reproducible:

Always

Steps to Reproduce:
1.create a replicated volume having two bricks
2.start the volume
3.Do a fuse mount using script mode as soon as volume is started
4.Immediately do two or more volume set command.

Actual results:

Mount will hang

Expected results:

Mount should succeed. 

Additional info:

Comment 1 Anand Avati 2014-10-30 05:43:35 UTC

REVIEW: http://review.gluster.org/9003 (rdma:client process will hang if server is started to send the request before completing connection establishment) posted (#1) for review on master by mohammed rafi  kc (rkavunga)

Comment 2 Anand Avati 2014-11-18 10:38:37 UTC

COMMIT: http://review.gluster.org/9003 committed in master by Raghavendra G (rgowdapp) 
------
commit 4a3c36ba002eaf9e77c6d71180fcc7d0a415d69f
Author: Mohammed Rafi KC <rkavunga>
Date:   Thu Oct 30 10:35:57 2014 +0530

    rdma:client process will hang if server is started to send
    the request before completing connection establishment
    
    in rdma, client and server will interchange their available
    buffers during the handshake to post incoming messages.
    Initially the available buffer is set to one, for the first message
    during handshake,when first message is received, quota for
    the buffer will set to proper value. So before receiving the message
    if server started to send the message, then the reserverd buffer for
    handshake will be utilised, then the handshake will fail because
    of lack of buffers. So we should block sending messages by server
    before proper connection establishment.
    
    Change-Id: I68ef44998f5df805265d3f42a5df7c31cb57f136
    BUG: 1158746
    Signed-off-by: Mohammed Rafi KC <rkavunga>
    Reviewed-on: http://review.gluster.org/9003
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Raghavendra G <rgowdapp>
    Tested-by: Raghavendra G <rgowdapp>

Comment 3 Niels de Vos 2015-05-14 17:28:15 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 4 Niels de Vos 2015-05-14 17:35:40 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 5 Niels de Vos 2015-05-14 17:38:03 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 6 Niels de Vos 2015-05-14 17:44:21 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user