[Red5] Memory Leak - Test Case

[Tyler Kocheran]

By the way, GREAT way to debug this thing. By giving us detailed information
like this, it helps us get to the source of the problem faster. Thanks,
Thomas!

On Thu, Jun 11, 2009 at 9:43 AM, Tyler Kocheran <rfkrocktk at gmail.com> wrote:

> Well, what appears to be happening is this.
> You're using AMF0, since the bug seems to occur in the
> org.red5.io.amf.Output<http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/io/amf/Output.java>class and not the
> org.red5.io.amf3.Output<http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/io/amf3/Output.java>class. However, on closer look, this bug may be affecting AMF3 strings as
> well, since the AMF3 Output extends the AMF0 Output. It seems that for a
> performance gain, a static final ConcurrentMap<String, byte[]> is held in
> memory, caching all Strings and their byte[] representations to make future
> acesses faster.
>
> Unfortunately, this cache appears to be unbounded, so if you've got a
> long-running server (which is something we all hope for ;] ), you've got a
> huge problem if you're using any remoting in your application, since all
> Strings and their byte[] representations are held *in memory indefinitely*.
> Just as in your testing example, it would be very easy for a rogue client to
> attack your server's RAM by using something as simple as the echo service,
> just passing random strings to RMI calls on an infinite loop. This is
> fixable, of course, we could probably fix it using EhCache which is already
> included in the trunk. The problem with Maps is that they're not so easy to
> set bounds for.
>
> EhCache, on the other hand, is extremely configurable, even clusterable,
> and can even overflow to disk and optionally create an eternal (persistent
> between server restarts) cache. I'm going to look into implementing it into
> the Output classes.
>
> On Thu, Jun 11, 2009 at 7:47 AM, Thomas Auge <auge at virtues.net> wrote:
>
>> Waiting a little longer after a little over 26000 loops, grep -c reports
>> 26032 string snippets in the live heap.
>>
>
>
>
> --
> And do this, knowing the time, that now it is high time to awake out of
> sleep;
> for now our salvation is nearer than when we first believed.
>



-- 
And do this, knowing the time, that now it is high time to awake out of
sleep;
for now our salvation is nearer than when we first believed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090611/55d1a041/attachment.html>