[Building Sakai] heads-up on 2.9.x upgrade: see jldap provider bug fixes at SAK-23689 and SAK-23719

[Sam Ottenhoff]

Hi Bill,

You and I already maintain our own JLDAP forks, so I'm assuming trunk
changes wouldn't be all that painful for us.  The argument to remove the
JLDAP cache is that it is redundant and thus confusing to developers and
administrators.  Currently, the user info is cached in two different places
for two different times.  The UserDirectoryService checks its cache and
then asks JLDAP for the user.  JLDAP then looks up against the
institutional LDAP, caches the data, sends it back to UserDirectoryService
which also caches the data.  I think we should just simplify this code and
remove all of the caching in JLDAP and set a nice, sane caching time for
UserDirectoryService with good instructions on how an institution can
easily change the timeouts.  Then the answer to institutions looking for
better user load performance have a nice answer: boost your timeToLive on
the UserDirectoryService cache to keep your user info in memory longer and
reduce the LDAP fetching.

--Sam


On Thu, Sep 19, 2013 at 2:02 PM, Niebel, William (wdn5e) <
wdn5e at eservices.virginia.edu> wrote:

>  Hi, Sam.
>     I don't see a trunk change to remove the ldap-specific cache, so there
> may still be time to influence a decision to drop the ldap-specific cache
> (or not).
>     It may be better for us at UVa to leave it in place.  We have a local
> mod to getUserFromEmail() to use an alternate, multi-valued, attribute
> which isn't mapped to Sakai user data.  This alternate attribute has one or
> more email addresses known as belonging to the user.  This allows the user
> to send mail to site mail-archive from any of those mail addresses, not
> restricted to the single-value mail attribute (which we still map into
> Sakai user data, and which is the only address which Sakai notifications
> are sent to, as usual).
>     Granted this lookup is relatively infrequent, but I thought I should
> let you know.  Thanks.
> Bill
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130919/c0090868/attachment.html