I've added some notes about our clustering direction for Resin 4.0 at 

The main capabilities that we want for 4.0 clustering are:

   1. dynamic servers (for load matching, and power savings)
   2. simplify the administration model

The main complexity of the current distributed session is that every  
server acts as a primary and a backup for some data.  So it's  
difficult or impossible for an administrator to know exactly what  
happens when a server goes down due to maintenance or a crash.

The new "triad" hub and spoke model simplifies that administration  
question.  All replication occurs on the triad hub servers.  So it's  
always safe to take down servers 4-64 at any time.  The 3 hub servers  
(servers 1-3) are critical, but administrators can take more care with  
them because it's only 3 servers, and they're known as being more  

Those two requirements sound relatively simple, but imply a good deal  
of underlying infrastructure work. For example, distributed sessions  
since we no longer have the concept of an "owning" server, which means  
I need to add a temporary leasing concept that gives the same  
performance gains.

For users, the changes should be mostly invisible.  The first 3  
servers in a cluster automatically form the triad, and all the  
replication and session caching happens under the covers using the  
current API.  Single and dual servers work just like today.  In other  
words, we're not adding a minimum requirement of 3 servers.

-- Scott

resin-interest mailing list

Reply via email to