[Red5] Memory Leak - Test Case

[Mondain]

Thanks for the patch TK and sorry I didn't answer sooner.. I'll review it
later for inclusion in trunk.
Paul

On Thu, Jun 11, 2009 at 1:07 PM, Tyler Kocheran <rfkrocktk at gmail.com> wrote:

> Sweet, I've pretty much got it migrated. JIRA is down, so I'll attach the
> patch here. It's passing all unit tests except the ScriptEngineTest, but I'm
> pretty sure this was failing before I did anything to Red5's internals.
>
> It is also passing extensive AMF3-related tests unique to the data object
> model of the project I'm currently working on, so that's good enough for me
> :) I'm not testing any AMF0 stuff, so I couldn't tell you confidently if
> there are any problems with it, but I don't think there are any existent
> problems since AMF3 is working like a champ.
>
> All configuration for the cache is found in the ehcache.xml file in your
> conf directory. I gave the caches some reasonable defaults, but they can (of
> course) be adjusted freely to allow more elements in memory and/or disk
> overflow. Also, the Red5 default diskStore has been moved to
> java.io.tmpdir/red5, to avoid any conflicts if anyone tries using EhCache
> with the default disk store. I can affirm that webapp's using EhCache will
> be unaffected by this change, so long as they use individual instance of
> EhCache and not the singleton. (I tried for about an hour to get a
> non-singleton working in the Output class, but it could not find the
> ehcache.xml file for the life of me. If you wanna migrate it to make it more
> flexible, be my guest :] )
>
> And without any further adieu, here it is.
>
>
> On Thu, Jun 11, 2009 at 10:44 AM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>
>> Since JIRA's down, I'll have to post this here. Paul, maybe you could help
>> out a little here: do you think that refactoring the string cache (as well
>> as the other caches in the Output classes) to use an EhCache Cache instance
>> rather than a ConcurrentMap is a good idea? If you think it's a good move, I
>> could definitely implement it.
>>
>> However, the cache would have to be moved from being a static member to an
>> instance member, so it could be injected. I don't know how/if the Output
>> classes are injected ever or not, but if you have any suggestions, Paul,
>> they'd be welcomed!
>>
>> Thomas, yes, you can modify your app to get rid of caching for the moment
>> until we get this fixed. For the org.red5.io.amf.Output class, comment out
>> line 505, and replace line 500 with "byte[] encoded = null;" Then, modify
>> org.red5.io.amf3.Output, changing line 145 to "byte[] encoded = null;" and
>> commenting out line 150.
>>
>> 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.
>>
>
>
>
> --
> 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.
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090611/28f676ec/attachment-0001.html>