Jarda,
We had to change our configuration to have one primary CAS server with the others being used as failover. Ehcache replication was not fast enough for round robin requests (we noticed this with service tickets). Ray ________________________________ From: [email protected] <[email protected]> on behalf of Jaroslav Kacer <[email protected]> Sent: April 19, 2016 04:51 To: [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/1461083636391.12857%40uvic.ca. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
