With a system like CAS, the main driver is the comfort level your team has with the technology. If your team is comfortable with Ehcache, go for it. If they already have memcached expertise, it may be worth it for them. Its basically the reason we have so many options :-)
Specifically with regards to off-heap caching, the main driver for that is typically high traffic sites where excessive garbage collection would affect their latency in unexpected ways. The odds of your CAS instance hitting that specific scenario may be minimal. Cheers, Scott On Wed, Aug 1, 2012 at 9:43 PM, <[email protected]> wrote: > 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 A-A 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 > > -- 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
