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 >
