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
