[Building Sakai] ContentHosting cache?

[David Horwitz]

I was wondering if there are a couple of patterns we want to look for:

1) Long running threads that call paths that use thread local
2) Miss-use of session scope
3) Use of Maps for caching

I can confirm that the case of the rebuildIndex thread that clearing the
ThreadLocal between sites seems to radicaly improve performance. As a
note one needs to be careful clearing ThreadLocal as it contains
securoty advisors:

            //Iterate through each site
            for (Iterator<String> c = contextList.iterator(); c.hasNext();)
            {
               
                //SAK-17117 before we do this clear threadLocal
                //get the security advisor stack otherwise later calls
will fail
                Object obj =
threadLocalManager.get("SakaiSecurity.advisor.stack");
                threadLocalManager.clear();
                threadLocalManager.set("SakaiSecurity.advisor.stack", obj);


D



On 08/16/2010 02:05 PM, Aaron Zeckoski wrote:
> As a general thought (only barely related), session type caching is
> risky because of issues like what Jim mentioned. Usually, the session
> (and session caches) is not accessible to services (as sessions are
> normally only accessible to the user they are associated with or
> security reasons) and therefore cannot be purged when data changes.
>
> Request based caches are normally pretty safe as long as they are
> being purged between requests (hibernate, for example, does a lot of
> request based caching in the hibernate Session - depending on how the
> transaction wrappers are setup). We should probably make sure that
> threadlocals are purged on each request start to make sure they are
> not being misused. This is probably not something we can just to as a
> blanket operation without looking at how they are being used in each
> case.
>
> It might be worth writing down a best practice or two for request and
> session caching. I have stuff in a conference presentation from 2007
> which I could cleanup and add to the wiki if people generally agree
> with the thoughts above.
>
> -AZ
>
>
> On Sun, Aug 15, 2010 at 10:14 AM, Jim Eng <jimeng at umich.edu> wrote:
>   
>> That cache had some problems, as I recall, and was not being used by the time I worked on CHS issues.  But I can't tell you what the problems were.
>>
>> CHS does a lot of thread-local caching (or did when I last looked) of data relevant to processing the user's current request.  It also saves too much info in session state, which has the effect of caching info for a specific user across requests.  As with many things in Sakai, the permissions and volatility of data make caching difficult.  CHS needs to answer questions for different users in different ways depending on the specific users' permissions, group membership, etc.  And inappropriate caching (as in session state) can result in a user being denied access to resources when permissions or availability change.  I suspect some of these issues may have come up with that early attempt at caching in CHS.
>>
>> I'm just saying it's not as easy as turning on caching.
>>
>> Jim
>>
>>
>> On Aug 15, 2010, at 4:39 AM, David Horwitz wrote:
>>
>>     
>>>  Hi All,
>>>
>>> While reviewing our production cache performance and pondering where
>>> Sakai migh benefit from more caches I discovered that ContentHosting has
>>> a cache but that its switched off by default.  I can't seem to find any
>>> documentation on this cache and wonder if there is a reason why it
>>> shouldn't be switched on?
>>>
>>> For the record it can be switched on with:
>>>
>>> caching at org.sakaiproject.content.api.ContentHostingService=true
>>>
>>>
>>> Regards
>>>
>>> David
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>
>>>
>>>       
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>     
>
>
>