[
https://issues.apache.org/jira/browse/FLEX-34648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642612#comment-14642612
]
Christofer Dutz commented on FLEX-34648:
----------------------------------------
Ok ... thinking about your "solution" using SoftReferences ... I think this
might only cure the symptom. It seems that the message instances are not
cleaned up, because the GC thinks they are still referenced. Same with the
FlexClient objects. So I started drawing a Map where FlexClient is referenced.
Looking for a place where eventually a reference might be kept. This map grows
large pretty fast. Eventually I might even think that the object a FlexClient
is woven into is too big for the GC to detect. Actually looking at the details
I think it might be a better idea to give the FlexClient, MessageClient,
FlexSession, Queues a refactoring ... currently it sort of feels like there are
pointers going to and forth between all the important objects. This shouldn't
be that way.
> [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)
