[Building Sakai] Caching options for 10.x

classic Classic list List threaded Threaded
2 messages Options
Stephen Marquard Stephen Marquard
Reply | Threaded
Open this post in threaded view
|

[Building Sakai] Caching options for 10.x

Hi all,

https://jira.sakaiproject.org/browse/KNL-1162 changes the MemoryService for 10.x and introduces some new properties which aren't yet documented in <a href="https://confluence.sakaiproject.org/display/DOC/Sakai&#43;10&#43;new&#43;properties&#43;and&#43;permissions" target="_blank" style="font-size: 10pt;">https://confluence.sakaiproject.org/display/DOC/Sakai+10+new+properties+and+permissions, so I have some questions.

If we enable:

memory.use.legacy=false

then the following warnings show up:

2014-06-26 14:29:52,991  WARN localhost-startStop-1 org.sakaiproject.memory.impl.BaseMemoryService - Creating MultiRefCache(org.sakaiproject.alias.api.AliasService.targetCache), GenericMultiRefCache is deprecated and will no longer work in the next release

2014-06-26 14:29:52,991  WARN localhost-startStop-1 org.sakaiproject.memory.impl.EhcacheMemoryService - Creating MultiRefCache(org.sakaiproject.alias.api.AliasService.targetCache), GenericMultiRefCache is not supported in the distributed MemoryService implementation, the refs handling will do nothing!


What does "the refs handling will do nothing" actually mean, in practical terms for a production system? Is it a genuine warning that one should care about?


Is it safe to use the new caching support WITHOUT a shared memory cache like Terracotta (as described at http://stackoverflow.com/questions/24145602/how-do-i-setup-session-replication-in-sakai-10) ?


Cheers

Stephen



UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.

_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Aaron Zeckoski-3 Aaron Zeckoski-3
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Caching options for 10.x

It means that the invalidation that was happening through the MRC
(multi ref cache) is no longer happening in the new caching. In terms
of real caches, that should only affect the security (authz) cache
which in the new caching uses a different means of invalidation which
is much much faster and over 10x smaller in terms of memory footprint.

The Alias cache is also affected but in our community polling it
generally had very little stored in it and the automatic expiration
meant that the data stayed relatively fresh anyway.

It is safe to use without being distributed because it uses
alternative mechanisms for cluster wide invalidation for the cases
where that had to handled (compared to older versions) but for Sakai
11 it will be important to have an actual distributed cache mechanism
if you are running in a cluster.
-AZ


On Thu, Jun 26, 2014 at 8:42 AM, Stephen Marquard
<[hidden email]> wrote:

> Hi all,
>
> https://jira.sakaiproject.org/browse/KNL-1162 changes the MemoryService for
> 10.x and introduces some new properties which aren't yet documented in
> https://confluence.sakaiproject.org/display/DOC/Sakai+10+new+properties+and+permissions,
> so I have some questions.
>
> If we enable:
>
> memory.use.legacy=false
>
> then the following warnings show up:
>
> 2014-06-26 14:29:52,991  WARN localhost-startStop-1
> org.sakaiproject.memory.impl.BaseMemoryService - Creating
> MultiRefCache(org.sakaiproject.alias.api.AliasService.targetCache),
> GenericMultiRefCache is deprecated and will no longer work in the next
> release
>
> 2014-06-26 14:29:52,991  WARN localhost-startStop-1
> org.sakaiproject.memory.impl.EhcacheMemoryService - Creating
> MultiRefCache(org.sakaiproject.alias.api.AliasService.targetCache),
> GenericMultiRefCache is not supported in the distributed MemoryService
> implementation, the refs handling will do nothing!
>
>
> What does "the refs handling will do nothing" actually mean, in practical
> terms for a production system? Is it a genuine warning that one should care
> about?
>
>
> Is it safe to use the new caching support WITHOUT a shared memory cache like
> Terracotta (as described at
> http://stackoverflow.com/questions/24145602/how-do-i-setup-session-replication-in-sakai-10)
> ?
>
>
> Cheers
>
> Stephen
>
>
> ________________________________
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the author.
> If you are not the intended recipient of the e-mail you may not use,
> disclose, copy, redirect or print the content. If this e-mail is not related
> to the business of UCT it is sent by the sender in the sender's individual
> capacity.
>
>
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"



--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"