> From: Marvin Addison
> Sent: Tuesday, July 14, 2015 6:33 AM
>
> Correct. What makes this acceptable in many if not most cases is that the lost
> state is SSO state where the effect on the user is to log in again. As failure
> modes go, that's graceful behavior.
Arguably true, but still not opti
Well, I say that but I am still butting against this issue with memcached ..
the default ticketRegistry.xml implementation works fine, but as soon as I try
and enable memcached (via verbatim instructions in the wiki) I keep getting a
Java cast error :
(there was a ticket on almost this exact i
John,
I did a fresh pull of 1.05-RC5 and aside from commenting out some of the
un-needed integrations did a successful build and execute .. so you were right,
at some point I contaminated the overlay.
Thanks,
Michael Holstein
Cleveland State University
Fr
>
> The primary reason I did not like the memcached implementation was that it
> is not truly fault-tolerant. As I understand it, any given key is hashed
> and stored on one of the available memcached nodes. A client that needs it
> performs the same hash, and tries to retrieve it from the same nod
Hello,
There are two things you must consider. JSESSION replication, and Ticket
Registry Replication.
If you have session-affinity configured you don't need to worry about the
first. (It also makes for very chatty application-servers if you do).
You have to make sure though that your entire clu
Hello everyone ,
We are using the CAS software from about one month , but until now we have
never used a Clustered CAS .
We have deployed the CAS on two nodes that have a load balancer in front of
them , let's call them N1 and N2.
on both nodes there are some CASified applications App1
