Task #2178
Story #2166: Hazelcast cluster errors need to be isolated
Use Lock.tryLock() (not Lock.lock()) in Metacat
Status:
Rejected
Priority:
Normal
Assignee:
Category:
Metacat
Target version:
Start date:
2012-01-09
Due date:
% Done:
0%
Milestone:
CCI-1.0.0
Product Version:
*
Story Points:
Sprint:
Description
In order to avoid potential deadlocks in Hazelcast, convert calls to Lock.lock() to Lock.tryLock() and introduce a timeout for the try. Also introduce a queue structure to re-process operations that need to be re-tried if the lock fails.
History
#1 Updated by Chris Jones almost 13 years ago
- Status changed from New to In Progress
#2 Updated by Chris Jones almost 13 years ago
- Status changed from In Progress to Rejected
Using lock.tryLock() in Metacat would require a task-based queue for all API calls to the REST API implementation so that if the lock fails, the task would be queued and retried later. This would be a major change to the way Metacat handles D1 REST requests. Since only Metacat is locking the pid for a given object, the chance of lock contention is very low, and blocking locks should work fine. Rejecting this for now.
