users@grizzly.java.net

Re: Comet - weird memory behaviour

From: FredrikJ <fredrik_at_robotsociety.com>
Date: Wed, 29 Apr 2009 05:29:16 -0700 (PDT)

gustav trede-4 wrote:
>
> whats of interest is:
> Is here a problem at all , is the max number of connections multiplied
> with
> the object size a real problem ?
>

Well, I would say that the undesired behavior (from my view) is that the
memory is never released. The fact that you during burst in concurrent
requests will allocate memory in order to cater for them and then cache the
objects to handle continued load is ok my book.

However, since the caches never decreases in size the current implementation
makes the assumption that it is ok to greedily hold on to memory in case of
another burst.

For instance, in my scenarios we can experience short time bursts of
requests and in the tests we can see that the caches grabs 256MB ram (and
this is still a small scale test). This memory is now allocated by the
caches until a reboot and is unavailable by any other business logic.

Assume that we would have other frameworks in the service stack that use the
same strategy, soon enough we would have a old gen space filled up to 1GB
just sitting there.

I have far too little insight in the underpinnings to suggest anything, but
perhaps some sort of idle-time-based eviction policy could be used here.

And once again, this is probably not critical for me and since I lack domain
knowledge of the actual implementation in grizzly I may just be plain wrong
;)


-- 
View this message in context: http://www.nabble.com/Comet---weird-memory-behaviour-tp23257612p23295840.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.