[
https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Buechel updated DIRMINA-1081:
---------------------------------------
Description:
In a few issues i read, that some users detect a hugh number of
ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I
dont know if this behaviour is still an open bug, so i opened this new issue.
Attached are two screenshot made by JProfiler. It seems, that the broadcast
method references these objects and does not deallocate them.
In my point of view this behaviour was getting better by using version 2.0.17
instead of 2.0.16, but this behaviour still exists.
PS: I am using Java 1.8.0_161b12 64bit
was:
In a few issues i read, that some users detect a hugh number of
ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I
dont know if this behaviour is still an open bug, so i opened this new issue.
Attached are two screenshot made by JProfiler. It seems, that the broadcast
method references these objects and does not deallocate them.
In my point of view this behaviour was getting better by using version 2.0.17
instead of 2.0.16, but this behaviour still exists.
> Increasing number of ConcurrentLinkedQueue$Node objects
> -------------------------------------------------------
>
> Key: DIRMINA-1081
> URL: https://issues.apache.org/jira/browse/DIRMINA-1081
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.16, 2.0.17
> Reporter: Alexander Buechel
> Priority: Major
> Attachments: linkedqueuenodes.png, recorded live allocations.png
>
>
> In a few issues i read, that some users detect a hugh number of
> ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I
> dont know if this behaviour is still an open bug, so i opened this new issue.
> Attached are two screenshot made by JProfiler. It seems, that the broadcast
> method references these objects and does not deallocate them.
> In my point of view this behaviour was getting better by using version 2.0.17
> instead of 2.0.16, but this behaviour still exists.
>
> PS: I am using Java 1.8.0_161b12 64bit
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
