We only went with a JPA registry for the sake of HA. Any ticket registry that allows multiple CAS servers to share a common ticket collection is acceptable for our needs. We don’t particularly need, for example, tickets to survive cluster-bounces.
On Jul 29, 2014, at 11:38 AM, Scott Battaglia <scott.battag...@gmail.com> wrote: > Please be sure you understand the trade-offs for each registry. Depending on > your use cases, EhCache or Hazelcast may not be a JPA-replacement. > > > On Tue, Jul 29, 2014 at 2:30 PM, John Gasper <jgas...@unicon.net> wrote: > Both support ticket replication: > ehcache: https://wiki.jasig.org/display/CASUM/EhcacheTicketRegistry > Hazelcast*: > https://github.com/Unicon/cas-addons/wiki/Configuring-HazelcastTicketRegistry > > *This is an add-on project that Unicon maintains. It might be worth > mentioning that the ehcache inventor is now Hazelcast's CEO. > > > On 7/29/14, 10:38 AM, Nick Sayer wrote: >> On Jul 29, 2014, at 8:15 AM, John Gasper <jgas...@unicon.net> >> wrote: >> >> >>> Hi Nick, >>> >>> I apologize in advance for this non-answer, but the JPA Ticket Registry has >>> been plague with deadlock issues for some time. I'd recommend looking at >>> another ticket registry such as ehCache or Hazelcast as an alternative to >>> JPA. You should still be able to do what you are planning with either of >>> those. >>> >> Thanks. I did see that note on the 4.0.0 JPA ticket registry wiki page, but >> still thought fixing it might have been a shorter path forward. We went with >> JPA for the sake of HA. Are either of those an HA solution (that is, >> parallel load balanced CAS servers sharing the ticket registry)? Where are >> they documented? >> >> >>> John >>> >>> On 7/28/14, 12:22 PM, Nick Sayer wrote: >>> >>>> We?re extending CAS 3.5.2.1 for our enterprise?s use. We?re using >>>> hibernate core 4.1.0.Final and validator 4.2.0.Final. One requirement is >>>> to allow installers to permit only a single TGT per user or permitting a >>>> single user to only persist TGTs that are associated with a single IP >>>> address. >>>> >>>> For the most part, we?ve got this working, but what we run into in >>>> production are database deadlocks when these features are enabled. >>>> >>>> The only difference of any consequence is this method: >>>> >>>> private void stripTickets(String id) { >>>> TicketGrantingTicket tgt = >>>> (TicketGrantingTicket)ticketRegistry.getTicket(id, >>>> TicketGrantingTicket.class); >>>> if (tgt == null) >>>> throw new RuntimeException("Could not find freshly minted >>>> TGT - should never happen!"); >>>> Authentication auth = tgt.getAuthentication(); >>>> if (auth == null) >>>> throw new RuntimeException("TGT has no authentication - >>>> should never happen!"); >>>> Principal myPrincipal = auth.getPrincipal(); >>>> if (myPrincipal == null) >>>> throw new RuntimeException("TGT auth has no principal - >>>> should never happen!"); >>>> InetAddress myAddr = >>>> (InetAddress)auth.getAttributes().get("InetAddress"); >>>> if (myAddr == null) { >>>> logger.warn("Newly minted TGT has no InetAddress."); >>>> return; >>>> } >>>> logger.trace("About to go through the ticket registry to >>>> stripTickets"); >>>> Collection<TicketGrantingTicket> toExpire = new >>>> ArrayList<TicketGrantingTicket>(); >>>> for(Ticket ticket : this.ticketRegistry.getTickets()) { >>>> logger.trace("Examining ticket " + ticket.toString()); >>>> if (!(ticket instanceof TicketGrantingTicket)) continue; >>>> TicketGrantingTicket thisTGT = >>>> (TicketGrantingTicket)ticket; >>>> if (thisTGT.equals(tgt)) continue; // Don't kill yourself! >>>> auth = thisTGT.getAuthentication(); >>>> if (auth == null) { >>>> logger.warn("TGT in registry has no >>>> authentication."); >>>> continue; >>>> } >>>> Principal thisPrincipal = auth.getPrincipal(); >>>> InetAddress thisAddr = >>>> (InetAddress)auth.getAttributes().get("InetAddress"); >>>> if (myPrincipal.getId().equals(thisPrincipal.getId())) { >>>> // It's the same user. Do we kill it? >>>> if (singleSessionPerUser || >>>> !myAddr.equals(thisAddr)) { >>>> >>>> logger.info >>>> ("Expiring TGT ID " + thisTGT.getId() + " for user " + >>>> thisPrincipal.getId() + " from IP " + thisAddr.toString()); >>>> toExpire.add(thisTGT); >>>> } >>>> } >>>> } >>>> logger.trace("Now we've got a ticket expiration list with " + >>>> toExpire.size()); >>>> for(TicketGrantingTicket ticket : toExpire) { >>>> ticket.expire(); >>>> this.ticketRegistry.deleteTicket(ticket.getId()); >>>> } >>>> System.err.println("Exiting the purge"); >>>> } >>>> >>>> >>>> So, in a nutshell, what we?re doing is iterating through >>>> this.ticketRegistry.getTickets() and selecting a list of tickets on which >>>> we wish to take action. Once we?re finished iterating, we go through the >>>> list of actionable tickets, expire each one and delete it from the >>>> registry. >>>> >>>> Is this method fraught with peril? Is there anything we can do to attempt >>>> to prevent deadlocks? They seem to happen in testing even with a single >>>> user just logging in once after another in isolation - which seems awfully >>>> fragile to me. >>>> >>>> >>>> >>>> >>>> >>>> >>> -- >>> John Gasper >>> IAM Consultant >>> Unicon, Inc. >>> PGP/GPG Key: 0xbafee3ef >>> -- >>> You are currently subscribed to >>> >>> cas-dev@lists.jasig.org >>> >>> as: >>> nsa...@silverspringnet.com >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >>> >>> > > -- > John Gasper > IAM Consultant > Unicon, Inc. > PGP/GPG Key: 0xbafee3ef > -- > You are currently subscribed to > cas-dev@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-dev > > -- > You are currently subscribed to > cas-dev@lists.jasig.org > as: nsa...@silverspringnet.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@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-dev
