Subject: Grouper Developers Forum
- From: Jim Fox <>
- To: <>
- Subject: [grouper-dev] HA grouper notes
- Date: Mon, 06 Dec 2010 19:45:12 -0800
re: Grouper dev action item regarding HA grouper
These are some questions that came up as we implemented an 'HA web
service', one that allows the service to respond quickly to the most
common requests and to continue service, for queries anyway, through
outages of the grouper registry. The design uses a clustered LDAP
service as a resource for selected requests.
1) Which queries will be HA?
About 90% of requests to our web service are two kinds of GETs:
. Is the user an effective member of a group?
. What groups is the user an effective member of?
The latter is the request our IdP makes.
2) Clients should be able to manually direct queries to the registry,
assuming that HA is the default.
3) The HA response must be complete and contain the same information
as a normal, registry response. A RESTful service normally includes
an ETag, or similar, with the response of any object that can also be
PUT, i.e. a membership. We do not make direct memberships HA for
this reason - our LDAP HA cannot generate the correct ETag.
4) The HA system must respond correctly to sequences such as this:
. One client PUTs a member to a group.
. Immediately, a different client GETs the member, using HA.
We allow PUTs to specify a 'synchronized' parameter which causes the
service to wait for LDAP update before returning a response.
5) The service must wait for all members of the LDAP cluster, not
just the master.
6) All appropriate ACls must be respected by the LDAP service.
7) If a Shibboleth IdP is using the Grouper attribute resolver it should
be HA as well.
- [grouper-dev] HA grouper notes, Jim Fox, 12/06/2010
- [grouper-dev] RE: HA grouper notes, Chris Hyzer, 12/08/2010
Archive powered by MHonArc 2.6.16.