Grouper Developers Forum

["Cramton, James" <>]

After a week of fighting other fires, I finally had a chance today to upgrade Brown’s Grouper QA environment to Grouper 1.3.0 rc1.  All in all, it went pretty smoothly, and I like the improvements to the UI quite a lot. I have a few observations on the process to share; most of these pertain to an institution upgrading a large implementation, and I’m not sure if any other institutions have taken this leap yet.  We’re in lockdown during our reading period leading up to final exams, but if all goes as planned, we should be able to deploy 1.3.0 to production shortly after reading period ends on May 16.

 

My notes on the upgrade from Grouper 1.2.1 to 1.3.0 rc1:

 

Environment:

App server: Sun 4100 x86 running 64 bit RHEL4

DB Server: Sun 4100 x86 running 64 bit RHEL4

No clustering or load balancing or redundancy, at least for now

 

Apache 2.2.4
Tomcat 5.5
Java 1.5
Linux Redhat Enterprise Server 4
Oracle 10g DB
SunOne Directory server 5.2

 

 

Scale of implementation:

65,000 active groups (mostly course groups)

17,000 active users

Nightly provisioning took 3 – 4 hours under Grouper 1.2.1

 

Observations:

-          Tool tips and infodots very useful, and will be well received by our end users

-          CSS tweaks needed in several browsers—typically, fonts are too bold and squished together, especially in buttons. Informal polling shows that appearance is fine in IE7 (Windows), Firefox 2 (Windows), but needs optimization in Firefox 1.5 (Linux), Firefox 2 (MacOS X)  and Safari 3.1.1 (MacOS X).

-          I used the Oracle sql script to update the DB schema from 1.2.1 to 1.3.0; this took about 12 minutes to complete, without incident.  By my way of reading it, the DB upgrade instructions recommend adding foreign keys using the addforeignkeys ant target, but the Oracle script already added them; the ant script coughed out all sorts of errors because of this double duty. I suggest revising the documentation to be more specific about when to use the ant target vs. DB-specific scripts.

-          I ran into errors when I first built using my old grouper.ehcache.xml file that were resolved by using the version of grouper.ehcache.xml from cvs. However, I’ve always been puzzled by which config files are packaged with the build. Sources.xml is certainly very installation-specific, but many of the other files, such as this cache file, and log4j properties, and others, are in cvs in states that are highly usable to most installations, at least for a start. I think it would be helpful to bundle a more complete set of config files, with config file documentation describing potential customizations.

-          As a point of reference, we’ve been experimenting with performance in our system, and we have yet to find a performance bottleneck. In particular, in this build, we upped the  comparator.sort.limit in the ui/resources/grouper/media.properties file to 50,000, and we have not been able to document a significant performance hit. Our largest group contains 17,000 members, and it displays a sorted list of members within 30 seconds, even when we display all 17,000 members on 1 page.  Why someone would want to do that is unclear, but it does perform well in our system.

 

We’ll let our nightly provisioning run as normal tonight, and I may have new observations from that process in the next few days. So far, however, it’s looking good!  Thanks to all the folks who worked on this build!

 

 

James Cramton

Lead Programmer/Analyst

Brown University

401 345 9795