[infinispan-dev] ISPN-863 - Thoughts / Questions

[Manik Surtani]

Yeah, I do agree that we should do this (best effort); just that we shouldn't fool ourselves into thinking that this is going to solve all problems caused by an OOM in Infinispan.

Also, re: middleware, this is often more than just JGroups + Infinispan (think JBoss AS, maybe SEAM, some web fwk, or Spring, and a whole bunch of user code that could be left unstable).

On 14 Jan 2011, at 14:54, Bela Ban wrote:

> 
> 
> On 1/14/11 3:35 PM, Manik Surtani wrote:
> 
>>> If a put() is the culprit leading to the OOME, we can definitely do
>>> something !
>> 
>> Galder is right though, even if the put() is the culprit, concurrent threads elsewhere (out of our control) would also be seeing OOMs and even if we free up memory by evicting, other threads may be in an unstable state.
> 
> JGroups tries to handle temporary OOMEs, and if Infinispan does that, 
> too, then it's only the app left which can cause OOMEs.
> 
> But at least the middleware (JGroups, Infinispan)  should go to great 
> lengths to make sure it handles OOMEs.
> 
> I see a big issue coming when we don't do this: as long as we don't have 
> a more or less even key/value distribution in Infinispan, there is a 
> chance we end up with some JVMs lightly loaded (in terms of memory) and 
> others almost full.
> 
> Even if we come up with a better distribution function, we cannot 
> prevent an application from using objects with uneven sizes that they 
> stick into the cache, e.g. thousands of smallish values and a few very 
> large values. This will also cause an uneven memory distribution, even 
> if the key distribution is even.
> 
> One thing we could do on the receiving side is to check memory only if 
> we receive a value that bigger than a certain size. Problem is what 
> happens when someone sets a value...
> 
> -- 
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org