Grouper Developers Forum

[Chris Hyzer <>]

On the call and on the list we have been discussing highly available web 
services (Im thinking about reads here not writes).  Some use cases:

1. Queries that aren't conducive to LDAP: e.g. if the limits are exceeded of 
LDAP, or maybe complex queries

2. If a deployment of grouper doesn't have LDAP, it doesn't need it

3. Queries that require logic, e.g. the attribute framework will need 
privilege decision point queries which require logic to get the answer

So I think web services should:

1. Slurp all data from the database into objects, and serialize them to disk.

2. For read operations, use those structures to make the decision

3. If web services are shutdown, deserialize from disk (and run recent change 
logs from the time it was last serialized)

4. If a certain amount of time has passed since the last slurp, slurp again.  
E.g. 24 hours

5. Have a thread which reads the change log every so often (e.g. every 2 
minutes, configurable), update the object structures.  Every so often (30 
minutes), serialize to disk

6. There could be an option of configuration for if you want readonly to do 
this, or just hit the db, or or this if the DB is unavailable

7. Yes, if you have this mode on, it will require a lot of memory 
(proportional to the size of the registry)...  we could swap this out for a 
local database or some other storage if we like, this part could even be 
pluggable

This way you should be able to run multiple web services instances, with a 
load balancer, and be highly available for readonly operations (when DB goes 
down)...

Anyways, I don't think any of this is all that complicated or hard or time 
consuming to build...  also, Im not going to work on this soon, just throwing 
out ideas...

Thanks,
Chris