Grouper Developers Forum

["Cramton, James" <>]

Hi Tom,
 
I used the tarball distribution of Grouper 1.3.0 rc1, which includes the 
following files in api/conf/:
 
buildGrouper.properties
ehcache.xml
grouper.properties
sqltool.rc
 
While cvs also includes the following files marked "dead," although some of 
them are still apparently needed:
grouper.ehcache.xml
hibernate.properties (I don't think this one is used anymore)
log4j.properties
sources.xml file (heavily modified per institution)
 
It's a bit confusing, but nothing a little debugging can't fix.
 
James
 
 
________________________________

From: Tom Barton 
[mailto:]
Sent: Mon 4/28/2008 5:19 PM
To: Cramton, James
Cc: 

Subject: Re: [grouper-dev] Brown running Grouper 1.3.0 rc1 in QA



That's good news, and I look forward to hearing what else you find in
your QA environment.

DB-upgrade doc bug noted and will be fixed.

I'll let UI folks comment on tweaks for browser/OS combinations you mention.

Regarding grouper.ehcache.xml, did you upgrade by cvs update or by
unpacking the tarball? I'd hope it doesn't matter, but apparently it
does, so the info may help to track down why.

Thanks!
Tom

Cramton, James wrote:
> 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
>
> 
>


so