Bug 947614
| Summary: | View rollback never unlocks stateTransferLock | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | dereed |
| Component: | Clustering | Assignee: | dereed |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.0.1 | CC: | jkudrnac, paul.ferraro |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-08-29 22:55:54 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
dereed
2013-04-02 20:55:51 UTC
Dan Berindei <dberinde> made a comment on jira ISPN-2989 If I remember correctly, we didn't unblock transactions on rollback because the coordinator was supposed to retry the cache view installation in less than 1 second, and re-acquiring the exclusive state transfer lock via StateTransferLock.blockNewTransactions was very expensive (because it had to wait on all the other running commands to finish). When a cache view installation eventually finished successfully, it would unblock the transactions. If the coordinator died, another node was supposed to pick up the coordinator role and install the new view, releasing the state transfer lock at the end. As such, I would close this issue as expected behaviour, and I would only try to fix the specific situations where the retry mechanism doesn't work properly. Mircea Markus <mmarkus> updated the status of jira ISPN-2989 to Resolved Mircea Markus <mmarkus> made a comment on jira ISPN-2989 see last comment. Per #c1 |