[
https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417560#comment-16417560
]
Alexander B commented on DIRMINA-1081:
--------------------------------------
We have some more information: In our scenario we have just one NioConnector
and one NioAcceptor, that take messages and broadcast them (in this case to one
client). We saw, that we have different behaviours on two different machines.
On a local machine (windows10, 64bit) with a single local consumer everything
works fine. On a machine (Linux) placed in a network and a consumer, which is
not running on this machine but is connected via a socket connection, we create
this memory problem (based on the given 8 classes, that were not deallocate
(linkedqueuenodes.png)) .
The results of getReadBytesThroughput() and getWrittenBytesThroughput()
respectively shows values between 20 and 50 kbit/s on the connector and
acceptor-side. Thats actually not much.
Are there any restrictions that we have to follow using a Linux-System / or any
other restrictions about network performances ? Based on (heap.png) we expect
that there are mina-buffers, that are not deallocated.
Thanks a lot
> 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 B
> Priority: Major
> Attachments: heap.png, 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)
