Bug 765349 (GLUSTER-3617) - rpc: Lock frames should not be subjected to timeouts
Summary: rpc: Lock frames should not be subjected to timeouts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-3617
Product: GlusterFS
Classification: Community
Component: rpc
Version: pre-release
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: krishnan parthasarathi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-23 11:04 UTC by krishnan parthasarathi
Modified: 2015-11-03 23:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Anand Avati 2011-09-23 10:11:35 UTC 
CHANGE: http://review.gluster.com/478 (As of today, all fops bail out after 30 mins by default. This is not desirable) merged in master by Vijay Bellur (vijay)
Comment 1 krishnan parthasarathi 2011-09-23 11:04:40 UTC 
Why?
Locks that are blocked at the server can starve for time periods greater than the configured timeout and be granted later. In the current scheme of things, we would unwind the lock frame at the client end thereby resulting in a STALE/orphan lock at the server end.
Note You need to log in before you can comment on or make changes to this bug.