Versions Compared

Version Old Version 2 New Version 3
Changes made by

Howard Gilbert

Howard Gilbert

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Now consider the same configuration with CushyFrontEndFilter inserted in front of the stack, and because of that you reconfigure the ticketRegistry.xml file so that Ehcache uses delayed replication for Service Tickets with the same parameters it uses for Login Tickets.

The browser submits a request to generate a Service Ticket. The Front End randomly chooses a CAS server, which creates the Service Ticket and sends it back to the

 

If you would like to see how this sort of programming is done, but you don't want to learn about real Front End devices, the same program logic is defined in the CushyFrontEndFilter.

In Java, an application can specify one or more Filters. A Filter is a Java class that can scan the Request as it is coming in to the application (CAS in this case) and it can scan the response generated by the application. The CushyFrontEndFilter scans incoming Requests an applies the logic for cases 1-3 to forward requests best handled by another node in the cluster.

If the programming is added to the Front End device, then it forwards request to the CAS server that issued the ticket and holds it in memory. However, without intelligent Front End programming the request arrives at a randomly chosen CAS node. At this point we have only two possible strategies:

  • The traditional idea is to configure the TicketRegistry to replicate ticket information to all the nodes or to the database server before returning the ST back to the browser. So 100% of the time you have a network transaction from one server to all the other servers and there is a delay for the network operation to complete added to the end of the Service Ticket generation. However, you should not forget that when the ticket gets validated the ST is deleted, and since you cannot configure Ehcache or any of the other technologies to do addTicket synchronously and deleteTicket asynchronously, then 100% of the time you get a second operation at the end of ST validation. 
  • With CushyFrontEndFilter the Service Ticket generation returns immediately. When the ST validation request comes in then there is a 1/n chance it will be routed to the right server by chance (that is, in a two node cluster it goes the the right place 50% of the time). Only if it goes to the wrong server is there a network operation, and then it will be from the server that received the request to the server that owns the ticket. There will only be the one exchange instead of two operations and two delays. 

So with Ehcache or any other synchronous replication strategy there is a 100% probability of two network transactions and delays, while with the Filter there is a 50% chance of no operation or delay, and a 50% chance of one operation and delay. Roughly speaking, the Filter has 25% of the overhead of the traditional mechanism.

But wait, you say, tickets still have to be replicated to other nodes for recovery if a node crashes. Yes, that is right, at least for Login TGTs and PGTs. However, Service Tickets are created, validated, and deleted so fast that if you are replicating ticket asynchronously, whether you use CushyTicketRegistry or Ehcache default replication every 10 seconds, that most of the time the ST doesn't hang around long enough to get replicated.

So while programming the Front End is the best solution, using CushyFrontEndFilter should clearly be more efficient than the current system of synchronous ST ticket replication.one of the two servers, with a 50% chance of selecting the one that generated the Login ticket. This is the case 3 situation (the CASTGC Cookie ticket), and since Ehcache replicates Login TGTs to all the nodes, there is no particular reason to route this request since all the nodes can handle it. If for some reason you decide to route to the login server, you expect to have a single network transaction half the time. If you disable CASTGC routing, then there is never a synchronous request or delay. The addTicket call does queue a ticket replication to occur eventually, but it will be batched up, happen in the background, and it delays nobody.

The application submits a request to validate the ST. Again there is a 50% chance the request will go to the node that issued the ST and require no network communication. In the other half of the cases, there is one synchronous network transaction.

So as Ehcache is configured now with synchronous replication, there are always two operations and two delays. With the Filter and asynchronous replication, there are two cases where you have a 50% chance of a network operation. If you disable CASTGC routing, that drops to a 50% chance of one network operation. Thus the Filter reduces the expected number of synchronous operations by at least 50% and perhaps 75%.

If you use CushyTicketRegistry instead of Ehcache, then you have no choice. Either the Front End has to do the routing or you have to use CushyFrontEndFilter.