[
https://issues.apache.org/jira/browse/FLEX-34648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645052#comment-14645052
]
Christofer Dutz commented on FLEX-34648:
----------------------------------------
As I wrote in my last post. The message-timeout will only be applied as long as
a client is connected. As soon as it's gone, you can enter whatever timeout you
want, the expiration-check is never done. I would suggest to set the
flex-client timeout as well as the destination timeout. These should already
work as they should. Could you please try that out and report if it eased your
pain?
Having a look at the code of FlexSession, FlexClient, MessageClient and all the
related classes, I would feel more comfortable in completely re-writing that
part of BlazeDS. In it's current state all the components are maintaining
references to each other, calling each other while setting helper-flags to
prevent infinite recursion. Some parts are only called in special occasions
(message timeout only for connected clients). The overall architecture
definitely gives a lot of room for improvement ;-) (Here's my attempts in
tracking down who's keeping references to what:
https://dev.c-ware.de/confluence/display/PUBLIC/Understanding+BlazeDS)
But I think this rewrite will take a while. What I could do is add code to
invalidate all MessageClients and all Queues as soon as the corresponding
FlexClient is invalidated. We'll probably ship a 4.8.0 with those fixes within
one or two weeks, but I guess I will have to rewrite some parts for a 4.9 (or
even 5.0).
> [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)
