[Red5] Memory Leak - Test Case

[Tyler Kocheran]

Yeah, I've already done that, It's passing fine :)
I'm determined to get a non-singleton CacheManager, I'm going to see if
there's any way I can make it happen.

 - TK

On Thu, Jun 11, 2009 at 1:24 PM, Art Clarke <aclarke at xuggle.com> wrote:

> Tyler, can you run the Red5 test suite on it.  That will actually test AMF0
> for you.
>
> - Art
>
> 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.
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>
>
> --
> http://www.xuggle.com/
> xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and
> video.
>
> Use Xuggle to get the power of FFMPEG in Java.
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>


-- 
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/35b3ca81/attachment.html>