[
https://issues.apache.org/jira/browse/FLEX-34648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644804#comment-14644804
]
Christofer Dutz commented on FLEX-34648:
----------------------------------------
Ok ... sorry for posting that much, but the picture ist getting clearer and
clearer :-)
So it seems the message-timeout is only used while a client is actively polling
the queue as the cleaning up is done in the flush method of the
FlexClientOutboundQueueProcessor. As soon as the Client has sopped polling this
method is no longer called causing the messages to remain in the queue, even if
they have expired.
Eventually it would be good to have some sort of MessageExpirationThread that
continuously cleans up queues.
But now the symptoms we have observed seem to make some sense.
> [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.sha...@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)
