[sakai2-tcc] Site caching

[Aaron Zeckoski]

I would say replication is not a good idea. Invalidation is desireable
and probably necessary but replication is a bridge too far in my
opinion (an a magnitude harder to get right).

-AZ


On Thu, Feb 17, 2011 at 7:02 AM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> Can we get more specific about the issues here and then we can flesh out how
> the caching could be reimplemented? I don't know much about the Sakai
> caching, but I do about caching in general and implementing a high level
> Site cache that has built in invalidation based on certain events shouldn't
> be too difficult.
> I assume replication is a major issue here too?
> regards,
> Steve
>
>
> On 17/02/2011, at 10:48 PM, David Haines wrote:
>
> Fragile is right, we just found a third serious caching bug in 2.7.  But
> waiting isn't much of an option.  Anyone running the current code with many
> users is going to run into problems that they will only find in production.
>  Personally I don't think 2.8 could be released in good conscience with
> these bugs and people should not run 2.7 until at least the obvious problems
> are fixed.
> - Dave
> David Haines
> CTools Developer
> Digital Media Commons
> University of Michigan
> dlhaines at umich.edu
>
>
>
> On Feb 17, 2011, at 2:36 AM, csev wrote:
>
> This code is extremely fragile.  My recommendation is a complete rewrite - I
> even wrote myself a JIRA many years ago to that effect:
> https://jira.sakaiproject.org/browse/KNL-89
> If you recall, over the years, every time someone touches this code, it
> breaks badly - it would seem as though SAK-11440 is similar to all other
> attempts to tune Site Caching.
> My plan in KNL-89 was to first remove *all* caching from Site and then test
> it thoroughly - and then make a nice, clean layer that should cache it
> nicely, touching the code at exactly one cut point and making very sure that
> invalidation was 100% perfect - and now of course - memory cleanup is
> perfect as well.
> As more and more tools use properties for their primary storage - properties
> will become an increasing problem if not dealt with properly.
> I fear that this is not something easily slid into 2.8 as a "quick fix" -
> the last thing we need is 2.8 shipping completely broken because of an
> unknown problem.     I would suggest that this needs a month of a person
> 100% dedicated to the problem - and we neither have the month nor the
> person.   So I also suggest that we *do not touch it at this time* and make
> this part of 2.9.
> /Chuck
> On Feb 16, 2011, at 8:10 PM, Matthew Jones wrote:
>
> This has probably been a problem for Sakai since ehcache was implemented in
> 2.5 (SAK-11440). This is not something someone would notice unless they had
> a high usage site, didn't restart often AND were looking at the heap dumps
> in a memory analyzer.
>
> On Wed, Feb 16, 2011 at 2:04 PM, David Haines <dlhaines at umich.edu> wrote:
>>
>> It is not new to 2.8, we found it in 2.7.1.
>> - Dave
>> David Haines
>> CTools Developer
>> Digital Media Commons
>> University of Michigan
>> dlhaines at umich.edu
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>



-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile