[
https://issues.apache.org/jira/browse/FLEX-34648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644788#comment-14644788
]
Christofer Dutz edited comment on FLEX-34648 at 7/28/15 6:17 PM:
-----------------------------------------------------------------
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.
There is a third timeout setting, but this seems to be in milliseconds, that
defines the lifespan of an individual message:
{code}
<destination id="myDestination">
<properties>
<server>
<message-time-to-live>10000</message-time-to-live>
</server>
</properties>
</destination>
{code}
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.
was (Author: cdutz):
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: [email protected]
> 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)
