If you change your socket or read timeouts for Java does it alter the
behavior at all?

Just trying to isolate how we can make it better, if possible.

-Scott

On Mon, Jun 22, 2009 at 7:00 PM, Johan Reinalda <
jo...@global.thunderbird.edu> wrote:

>  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 cas-user@lists.jasig.org as: 
> scott.battag...@gmail.com
>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to