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 >> > >
