Logical file deletes can spuriously timeout

Description

A regression introduced by , can cause a file detach to timeout, if another client is momentarily updating empty scopes or relationships.
changed the way the delete timeouts were handled, so that it it would not block others, by instead checking for a lock then sleeping.
However, detach also makes other locking calls to check for empty scopes and update relationships and the same 0 timeout was being used as a result of the change.
If another client was in that, short-lived locking phase, the detach would fire an instant DFS timeout, which was returned to the client.

The 0 time timeout was supposed to be for the file locks, to avoid deadlock, it was not supposed to effect the exclusive locking that empty scope and relationship checking performs.

Change those timeouts to use the DFS default timeout.

Conclusion

None

Activity

Show:

Jacob Cobbett-Smith March 3, 2015 at 9:19 AM

NB: This issue cause timeout errors that look like this:

[ 11: DFS Exception: 11: Lookup connection timeout: SDS: Lock timeout SDS Reply Error : SDS: Lock timeout Lock timeout trying to establish lock to Files/, existing lock info: Locks on path: /Files/

Richard Chapman January 23, 2015 at 9:42 AM

Fixed in 4.2.12-2

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Components

Assignee

Reporter

Priority

Fix versions

Pull Request URL

Created January 22, 2015 at 5:57 PM
Updated March 3, 2015 at 9:19 AM
Resolved January 23, 2015 at 9:42 AM