Bug 900481 (JBPAPP6-1418)
| Summary: | CLONE - Shutdown in REPL SYNC results in TimeoutException: Unable to acquire lock after | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Radoslav Husar <rhusar> |
| Component: | Clustering | Assignee: | Paul Ferraro <paul.ferraro> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jitka Kozana <jkudrnac> |
| Severity: | high | Docs Contact: | Russell Dickenson <rdickens> |
| Priority: | high | ||
| Version: | 6.0.0 | CC: | atangrin, jkudrnac, lthon, misty, paul.ferraro, rhusar, sgilda, simone.gotti |
| Target Milestone: | --- | ||
| Target Release: | EAP 6.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/JBPAPP6-1418 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-08-27 10:44:56 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 900611 | ||
|
Description
Radoslav Husar
2012-05-21 14:37:03 UTC
Link: Added: This issue Cloned from AS7-4813 Link: Added: This issue is incorporated by JBPAPP-7577 Workflow: Removed: GIT Pull Request workflow Added: jira Security: Added: Public Docs QE Status: Added: NEW Labels: Added: eap6_need_triage Link: Added: This issue is a dependency of JBPAPP-9290 Link: Removed: This issue is incorporated by JBPAPP-7577 Release Notes Docs Status: Added: Documented as Known Issue Release Notes Text: Added: A <code>TimeoutException</code> can occur during node shutdown when using REPL SYNC cache mode. The root cause of this issue is still under investigation. Affects: Added: Release Notes Labels: Removed: eap6_need_triage Added: eap601candidate Labels: Removed: eap601candidate Added: eap601-qe-triage I did not see this exception during EAP 6.0.1.ER2 testing. Not approved for EAP 6.0.1. If this should be reconsidered, please add the label: eap601-qe-triage Labels: Removed: eap601-qe-triage Writer: Added: mistysj Jitka, is it fixed then? This affects how we release-note it. Release Notes Docs Status: Removed: Documented as Known Issue Added: Needs More Info We need feedback from development here. Paul, can you please comment? I pinged Paul Ferraro on IRC. He said he would comment on this JIRA today. I'm fairly certain that this issue was made obsolete by the fix for https://issues.jboss.org/browse/AS7-5379. Previously, commits were sent asynchronously, regardless of cache mode. Now, when using synchronous mode, commits will be sent synchronously. Consequently, the condition described by Dan's last comment in AS7-4813 will not happen. Not quite - because commits were sent asynchronously, it meant that a request for a given session will return before the cache operation completes - thus a subsequent request can be received by another server (because the server is being shutdown, requests for the particular session will get redirected to another node), and the lock acquisition for that session could contend with lock acquisition by the original node's commit. Paul, thanks for the clarification. Release Notes Docs Status: Removed: Needs More Info Added: Documented as Resolved Issue Release Notes Text: Removed: A <code>TimeoutException</code> can occur during node shutdown when using REPL SYNC cache mode. The root cause of this issue is still under investigation. Added: A `TimeoutException` with the message `Undable to acquire lock` could sometimes occur during node shutdown when using REPL SYNC cache mode. This occurred because commits were sent asynchronously regardless of cache mode. Therefore, request for a given session could return before the cache operation completed. A subsequent request could be received by a different server, since requests to a server which is shutting down are redirected to a different node. The lock acquisition for that session could contend with lock acquisition by the original node's commit. Commits are now done synchronously so there should not be any issues acquiring locks. I've documented this as a resolved issue, based upon Paul's feedback. It seems like the JIRA should be "Resolved" in that case, but I will leave it up to others. Release Notes Docs Status: Removed: Documented as Resolved Issue Writer: Removed: mistysj Release Notes Text: Removed: A `TimeoutException` with the message `Undable to acquire lock` could sometimes occur during node shutdown when using REPL SYNC cache mode. This occurred because commits were sent asynchronously regardless of cache mode. Therefore, request for a given session could return before the cache operation completed. A subsequent request could be received by a different server, since requests to a server which is shutting down are redirected to a different node. The lock acquisition for that session could contend with lock acquisition by the original node's commit. Commits are now done synchronously so there should not be any issues acquiring locks. Docs QE Status: Removed: NEW Closing as per last comment. |