You are correct, it's soft references I wanted to say, not weak :).
Less sleeping than needed for the last two weeks does that.
I understand it's no silver bullet, but it might help survive bursts,
for the prize of having to fill up part of the cache once the burst is
over. A proper eviction policy would work better, but this would be a
last resort, but at least we could be sure that our apps won't stop
due to having memory reserved for some objects that might not be used
in a long time.
S!
D.
2009/4/28 gustav trede <gustav.trede_at_gmail.com>:
>
>
> 2009/4/28 Daniel Lopez <greeneyed_at_dev.java.net>
>>
>> As an added bonus, sorry if it already is implemented like that as I
>> had no time to look at the source, one could implement the cache using
>> Weak References, so it does not contribute to an OOM under any
>> circumstance.
>
>
>
> whats of interest is:
> Is here a problem at all , is the max number of connections multiplied with
> the object size a real problem ?
>
> The fact that the cache size becomes the max number of actual connections is
> well known,
> and something that had been discussed before.
>
> There is no silver bullet solution to the problem , each design has its own
> drawbacks.
>
> Its not weak references that are used for cache, its soft .
> due to that weak would get cleared on the first GC and cause for poor cache
> performance..
>
> we must know that the worker threads dont choke on extreme load situations
> on high core servers due to a cache mechanism that works well for a specific
> labtest on a specific number of cpu cores that make us thinks "all is ok".
>
> its possible to use per thread cache with limits in a standard arraylist,
> but that has other side effects,
>