I don't have a preference, honestly. My main goal is to put a stable and manageable system in place. I don't have any doubt these guys can manage anything that I stand up, but I'd prefer to deliver them a finished product that just runs and, aside from integrating future apps, doesn't require frequent interaction.
Is there a compelling reason to move it outside of the heap? I'd assume that heap size management could be an issue, but if it's a dedicated server can't we just tune the heap size larger? On , Scott Battaglia <[email protected]> wrote: > If you prefer your cache to live outside the heap, there is also a > memcache version. > Cheers > Scott > On Aug 1, 2012 8:58 PM, [email protected]> wrote: > Thanks for the input. I had seen the article on JPATicketReg, which > really got me looking into the persistent registries available, and I > think that a lot of the types of problems cited come up frequently in > most of the other disk-based persistent shared registries. I'd read a > little about the shared memory caching, but didn't realize it was > included in the 3.5 distribution. I'll focus on EhCache and post my notes > up when I'm done. > On , "William G. Thompson, Jr." [email protected]> wrote: > > > > > > On Wed, Aug 1, 2012 at 3:08 PM, CHAD CAMPBELL [email protected]> > wrote: > > > > > > I am working with a university to implement CAS for SSO. I have some > experience managing the CAS instance at my current institution, but we > are running a single instance in a virtual environment and this > university has asked for a highly available, load balanced cluster. > > > > > > > > > > > > I have pushed back on the requirement for clustering some. In my > experience AA clusters introduce at least as many points of failure as > they resolve. The only time I would suggest it is if the institution has > way more load than it can handle on a single host and/or has the > available staff to dedicate to troubleshooting issues that arise. Digging > through some of the bug trackers for various products, I've seen a number > of potential pitfalls that could crop up. My intention is to continue to > advise them to deploy the server in a virtual environment and handle > availability concerns there, but I'm preparing for them to insist on full > Active-Active HA clustering. > > > > > > > > > > > > Build info: RHEL6, Tomcat 7, CAS 3.5, JDK1.7(ish), planning on using > the Maven2 overlay build to ease administration. > > > > Here's the questions I have from what I've gathered so far. Hopefully > someone can respond with actual experience and either confirm or allay > concerns: > > > > > > > > > > > > SQL vs NoSQL: For shared ticket registry, I've seen a lot of bugs in > most of the mysql based models, usually due to mysql behaving > unexpectedly. Is this something that is consistently true? > > > > Many folks have run with the JpaTicketRegistry successfully, but you > have to be willing to take on the complexity of the RDBMS, Hibernate, > etc. In my opinion this is no longer worth it given the other options > that exist today. > > > > > > > > Also see: > http://jasig.275507.n4.nabble.com/JpaTicketRegistry-A-Sinking-Ship-td4256973.html > > > > > > > > Version: From what I've read, the 3.5 release of CAS has been an > improvement in this area, but it's still relatively new. Any advice on > versions of any interconnecting pieces that should be avoided? > > > > 3.5 is the recommended version for new deployments. It is a modest > evolution of the well respected 3.4.x line with helpful new features. > > > > > > Suggestions for adoption: Any suggestions for a blank slate build? The > simplest, easiest to manage, least error prone product capable of > handling two nodes in an active-active capacity would be ideal. They have > some very intelligent people on staff, but not enough of them, so I don't > want to bog them down with an overly engineered behemoth that keeps them > up at night. > > EhcacheTicketRegistry that ships with CAS3.5. Simplest way to get a > robust active-active multi-node CAS deployment. > > > > > > > > > > > > > > > > Personal Experience: Any personal experience to share on setting up and > managing a similar environment? If you've made a selection that works > flawlessly, or one that has made your life hell, I'd love to hear about > it. > > Unicon has done numerous mulit-node CAS deployments leveraging the > EhcacheTicketRegistry, even before it was part of the Jasig distribution. > > > > > > > > > > I've already reviewed a number of documents, so I have some background > info to make a selection, but I'd be interested to hear from someone with > experience deploying and managing this type of environment. > > > > > > Hope this helps. Do keep us in the loop on your deployment. > > > > > > Best, > > Bill > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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 > > > > > > > > > > > > -- > > 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 > -- > 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 > -- > 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 -- 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
