I’ve brought this topic up on this list multiple times with no answer, most recently:
https://groups.google.com/d/msg/jasig-cas-user/YOEFTnseBjs/msFyW0P-fk4J (our environment info is in this thread for reference) We’ve run into similar issues, as we’re concerned with immediate (sub-second) TGT availability. Even with some java/memory tuning tweaks, the issue was uncorrectable. Alas our solution to date was switching to synchronous TGT replication which has served us well for the past year or so now with no issue. You may have other issues, as I don’t recall anything similar to your Spring locking issues. Admins, Could we get the docs changed if no one has a reason for TGT replication via EHCache to be asynchronous? — Raymond Walker Software Systems Engineer StSp. ITS Northern Arizona University From: <[email protected]> on behalf of Jaroslav Kacer <[email protected]> Date: Tuesday, April 19, 2016 at 4:51 AM To: "[email protected]" <[email protected]> Subject: [cas-user] Synchronous replication of TGT - Is it safe? Hello everyone! We use CAS 4.0 with EH Cache ticket registry in a clustered environment. Initially we set up the registry and ticket replication according to this documentation: http://jasig.github.io/cas/4.0.x/installation/Ehcache-Ticket-Registry.html It uses synchronous replication for STs and asynchronous replication of TGTs. This configuration worked just fine for us, until we deployed an application that uses CAS as OAuth token provider. We immediately hit a problem that the TGT was not always available on the 2nd node of CAS cluster before the application wanted to verify the OAuth token (=TGT); it was a question of 1-2 seconds, sometimes it was already available, sometimes not. Therefore, we switched over to synchronous replication of TGTs, which solved this problem. However, I am not 100% sure this is a safe solution. May I ask if someone has already used synchronous replication for TGTs? I’m asking because since then, we have been randomly getting long delays when validation user credentials on login. It can be seen in the logs that these delays are cause by a log inside Spring Webflow: SEVERE: Servlet.service() for servlet [cas] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to acquire conversation lock after 30 seconds] with root cause org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to acquire conversation lock after 30 seconds at org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44) at org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69) at org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51) at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:166) at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925) This happens randomly, about once per day. I found some related information in CAS Jira here: https://issues.jasig.org/browse/CAS-993 And also some older discussion on this list: https://groups.google.com/forum/#!topic/jasig-cas-user/k3wcrKpO69c The Jira ticket says an authentication handler that takes too long can cause such errors. But I’m not sure I understand it completely. Specifically, I’d like to know: · Can synchronous replication of a single TGT cause the authentication handler not to return at all or return after a long time? I would say it can cause long delays only but I’m not sure. · Even if the authentication handler is still running, how can we get the timeout on the lock when all this happens after a single form post, i.e. in a single request, i.e. in a single thread? The lock belongs to a particular web flow execution and just the thread processing the post request should try to lock it, shouldn’t it? I would really appreciate if someone could share his experience here or explain me what exactly happens there when the lock cannot be acquired. Thank you! Best Regards, Jarda -------------------------------------------------- Jaroslav KAČER IDC | Web Channel Team | Application Developer E-Mail: [email protected]<mailto:[email protected]> Skype: jkacer.idc -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/BY2PR02MB13327E398AF1E8FAE27F76B1CF6C0%40BY2PR02MB1332.namprd02.prod.outlook.com<https://groups.google.com/a/apereo.org/d/msgid/cas-user/BY2PR02MB13327E398AF1E8FAE27F76B1CF6C0%40BY2PR02MB1332.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/a/apereo.org/d/optout. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/C3AE6082-C670-48F0-AE7B-D92C2BFEEC22%40nau.edu. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
