Ok, thanks, then we'll probably start using ehcache, although the BasicHttpCache is now working fine as first layer in front of our memcached pool now.
Is there a good list somewhere for containers to know what exactly you should change in Shindig to make it production worthy? Without any live OS experience it's hard to think about all the use cases and bottlenecks, so some notes from the developers can be useful, security, performance and feature wise. For example, we've been using the BasicHttpFetcher, BasicGadget/MessageBundleFactory in production and it has been running quite smoothly, with very little changes in those areas and no performance problems, apart from the BasicHttpCache. Kevin Brown wrote: > 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] >> >> >> >> >
