I can attest that the ehcache implementation holds up in production
usage.
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]
