On Thu, Nov 6, 2008 at 12:33 PM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> I can attest that the ehcache implementation holds up in production usage. Indeed. It seems to me that there's no reason not to pull this in. I'll get a patch going now. > > > On Nov 6, 2008, at 12:23 PM, Kevin Brown wrote: > > Actually, we should probably just get rid of the LRU cache here (the real >> culprit) and make everything use EH cache. I don't see any strong reason >> not to -- the cache provider can be changed to simply *always* use named >> instances, which certainly simplifies things. >> >> Ian, you wrote the ehcache implementation. Do you have any strong opinions >> here? >> >> On Thu, Nov 6, 2008 at 9:51 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: >> >> By convention, Basic* are not considered production worthy. For the HTTP >>> cache, I'd never use a pure in memory solution, and through ehcache >>> configuration you should be able to wire something more robust fairly >>> easily. >>> >>> We can probably make this class thread safe anyway though. If we're >>> really >>> worried about performance, a ReadWriteLock would probably do the trick. >>> >>> >>> On Thu, Nov 6, 2008 at 9:26 AM, Marijn Speelman <[EMAIL PROTECTED]> wrote: >>> >>> Hi, >>>> >>>> The default BasicHttpCache is using an unsychronized LinkedHashMap which >>>> can cause very strange problems when it has multiple threads talking to >>>> it. We've been using this class in combination with a memcached backend >>>> (when the http response is not in the in-memory cache we retrieve it >>>> from our main memcached pool). >>>> >>>> The problem that appears after a while is that the max capacity of the >>>> LRU cache is not being respected, eventually resulting in an OOM error >>>> after a day or two (with about 88,000 cached objects while our max >>>> capacity was set to 10,000). >>>> >>>> I know it says 'Basic' but I expected it to be simple, not 'unsuited for >>>> production' :) For now I just made the three functions (add,get,remove) >>>> synchronized, which of course results in a performance penalty but as it >>>> seems, not a significant one (especially compared to a server leaking >>>> memory ;)). >>>> >>>> The reason why we used the BasicHttpCache and for instance not ehcache >>>> is that it was just what we needed (a really really simple in-memory >>>> cache), and we're still using an older shindig version of around May >>>> that didn't have ehcache in it yet. >>>> >>>> I suggest making the BasicHttpCache thread safe, or at least adding a >>>> comment to warn people that it's not suited for production for this >>>> reason (but then again, making it thread safe but slower is probably >>>> fine for non-production as well). Or was I just silly for using this in >>>> a production environment? :) I find it quite hard to tell what exactly >>>> is production ready in Shindig, and what is just a sample implementation >>>> you should never really use. Is there some documentation on this >>>> (configure this, create a better class instead of class X that supports >>>> this and that)? >>>> >>>> Marijn >>>> >>>> >>> >>> > Paul Lindner > [EMAIL PROTECTED] > > > >
