All,
Here is the scenerio:
2 CAS3.3.2 server behind a loadbalancer, active/standby, server1/server2.
Both have repcache setup, replication is working fine, both deploy configs
are pointing to both repcache servers, but in opposite order
(ie. local repcache ip first, although this seems to make no difference)
ticketRegistry.xml:
<bean id="ticketRegistry"
class="org.jasig.cas.ticket.registry.MemCacheTicketRegistry">
<constructor-arg index="0">
<list>
<value>10.89.9.31:11211</value>
<value>10.89.9.32:11211</value>
</list>
</constructor-arg>
...
</bean>
To test failover, I stop tomcat and kill (-9) the memcache process on the
primary, server1. The failover kicks in, and the standby server2 becomes active.
Howver, on a browser bringing trying to get a session ticket,
I get an HTTP 500 error, seemingly caused by the fact that repcache1 went away.
---------------------------
root cause
org.springframework.webflow.engine.ActionExecutionException: Exception
thrown executing [annotatedact...@ed753a targetAction =
org.jasig.cas.web.flow.generateserviceticketact...@1ab46cd, attributes =
map[[empty]]] in state 'generateServiceTicket' of flow 'login-webflow' --
action execution attributes were 'map[[empty]]'; nested exception is
net.spy.memcached.OperationTimeoutException: Timeout waiting for value
...
---------------------------
About 15-20 seconds later, after several page refreshes, the session page
renders
again on server2 and I am redirected back to my app. Now the upstream has
figured out the socket is dead, and
logs show that there now a reconnect attempt to repcache1 going on...
Is there a more graceful way to handle this situation? Is there a way to trap
this first error ?
Thanks,
Johan
Thunderbird School of Global Management
Glendale, AZ
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
