[Building Sakai] Unresponsive jvm .. any suggestions?

Sam Ottenhoff ottenhoff at longsight.com
Wed May 7 11:18:50 PDT 2014


>
> Yes, it seems like the JVM is running out of memory, but we just
> configured JMX on one of app servers last night so we hope to get a
> definitive sense of things then.
>


If the JVM is running out of memory, the LDAP errors may be an effect of
Tomcat not having any spare resources instead of a cause of your issues.



>
> We don't have that memory.org.sakaiproject.user.api.UserDirectoryService.callCache
> configured in sakai.properties so we'll enable that.
>


That line in sakai.properties will just modify the default cache settings.
 The default cache is setup to hold user information for 5 minutes only.


>
> Users that no longer exist on the LDAP server (I think they've been
> de-provisioned, but are still in a 1000(s)+ user orientation course for new
> students).
>
> Could a large volume of this type of transaction generate that error?
>

I doubt it.  But regardless, because Sakai only caches users it finds, the
de-provisioned users are slowing down page accesses.  So if you have 1000
users in a site, and 100 of those users are no longer in LDAP, Sakai will
cache the 900 users it finds in LDAP but will not cache anything about the
100 users it does not find in LDAP. This means that every time Sakai needs
the full roster (gradebook, roster, site info), it will re-query the LDAP
server for those 100 users.

In Sakai 2.9, the JLDAP code was improved so that the getUsers() call makes
one query to LDAP instead of individual queries for each user. In Sakai 10,
the site-manage code was improved so that admin users can remove
orphaned/de-provisioned users from sites.

--Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140507/97adbe18/attachment.html 


More information about the sakai-dev mailing list