flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-34648) [BLAZEDS]Memory Leak occurred in AsyncMessage when sending alot of
Date Tue, 28 Jul 2015 18:16:04 GMT

    [ https://issues.apache.org/jira/browse/FLEX-34648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644788#comment-14644788
] 

Christofer Dutz commented on FLEX-34648:
----------------------------------------

Ok ... so a while of debugging I found out that the default settings of BlazeDS might not
be quite ideal. For example the cleaning up of Idle FlexClient instances works as soon as
you explicitly set 
{code}
<flex-client>
    <timeout-minutes>5</timeout-minutes><
/flex-client>
{code}
Default is 0 which doesn't register a timeout handler at all. If I set this to the 5 minutes,
the memory consumption grows until the timeout. I was expecting the memory to be freed as
soon as the FlexClient is invalidated, but it seems that this is not the case. The queues
stay filled with the number of messages as the FlexClient was invalidated. A further investigation
showed, that I can add a second timeout to the definition of the destination:
{code}
<destination id="myDestination">
    <properties>
        <network>
            <subscription-timeout-minutes>7</subscription-timeout-minutes>
        </network>
    </properties>
</destination>
{code}
With this code I can see that the queues stop growing after 5 Minutes and after 7 minutes
the messages are correctly cleaned up.
While I think not registering the FlexClient timeout is a valid setting as for example the
FlexClient could be bound to an ordinary HttpSession and invalidated manually by a HttpSessionListener,
but I think as soon as a FlexClient is invalidated, all of it's subscriptions should be invalidated.


It would however be good, if you could please check if you have set these properties and if
you haven't if this eases your memory-related pain. Currently setting both settings to the
same timeout should work quite well ... I'll investigate why destination subscriptions are
not cleaned up as soon as the related FlexClient is invalidated.

> [BLAZEDS]Memory Leak occurred in AsyncMessage when sending alot of 
> -------------------------------------------------------------------
>
>                 Key: FLEX-34648
>                 URL: https://issues.apache.org/jira/browse/FLEX-34648
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: BlazeDS
>    Affects Versions: BlazeDS 4.7
>            Reporter: ibrahem.shawky@gmail.com
>            Assignee: Christofer Dutz
>            Priority: Critical
>
> a memory leak occurred when sending alot of AsyncMessage through BLAZEDS in a real time
systems which is heavilly using messaging however we are increasing the jvm heap size  to
4 GB 80% of the size is occupied by AsyncMessage objects this is very clear from the generated
heap dump.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message