Grouper Developers Forum

[Steve Edgar <>]

I am working with Joy Veronneau at Cornell University on a project to  
replace our current AuthZ system with Grouper.

Quick background:  I've been following the list for a while, and have  
written several software components against the Grouper API.  I have  
also learned a lot more about LDAPpc than planned :).

Question 1.

Does Grouper support concurrency?  That is, can I have an instance of  
Grouper UI running in Tomcat on one machine, and have another JVM  
running on a different machine, running software which uses the  
Grouper API, but points to the same db tables as the Grouper UI  
instance?

Our current AuthZ solution, called "Permit Server", was developed in  
the mid-90s, using an in-house protocol and hand rolled GDBM tables.   
It is a bit short on features, but is super fast and can handle big  
groups.  I have written a "gateway" which looks like Permit Server on  
one side, and talks to Grouper on the other.

Currently, this gateway uses web services to talk to Grouper, but I  
am interested to know if I could instead have this gateway directly  
use the Grouper API jars.  That would make 2 instances of the Grouper  
API running concurrently on 2 separate machines:

1) The UI
2) The Gateway

Is this practical?  If so, are there special config settings required  
to get the needed db locking?

Question 2.

Our current AuthZ system has one monster group of 190K members.  I  
have found that LDAPpc can not sync a group of this size, and fails  
with the error "Broken pipe".  I am new to the Java/JNDI/DB  
landscape, but the problem appears to be ...

You can pile 200K hasMember entries into a BasicAttribute, but when  
you hand that to createSubcontext, it goes boom, and not with any  
exception which createSubcontext throws.

I do not know the exact max size a BasicAttribute can be before  
createSubcontext barfs, but my tests show it is somewhere around 95K  
hasMember entries.  I am using Java version 1.5.0_07.

I can keep appending, using modifyAttributes, after an initial write  
of 95K entries, so I can get all the entries in there, but not using  
LDAPpc.  Once they are all in there, a sync with LDAPpc should work,  
as only the deltas will get used.

I am curious to know if anyone else run into this situation, and if  
so what solution was used.

Question 3.

If LDAPpc is running with the -interval option, it does not appear to  
write to disk the last time it checked all the groups.  Is this correct?

If so, LDAPpc running under "cluster control" on a Solaris cluster  
would do a full compare on every group when the cluster software auto- 
restarted it.  I can add a function to write the time/date of the  
last compare, and read that on startup, but am curious if there is an  
alternative.

Is anyone running LDAPpc under cluster control?

-- Steve.