Affects: Release Notes project_key: JBPAPP6 Description track on AS7-4813.
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.