[
https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16418614#comment-16418614
]
Emmanuel Lecharny commented on DIRMINA-1081:
--------------------------------------------
I would add one thing:
Due to the asynchronous very nature of {{NIO}}, which is a bit masked by the
{{MINA}} framework, you can't really wait for the result of an operation (like
a broadcast), as I said before.
That means the set of futures is pretty much useless if you don't manage that
in a separate thread. Typically, if you want to execute an action when all the
sessions have been sent the message, then you have to handle each session
{{messageSent}} event, and remove the associated future from the set, up to the
point it's empty - also remove future for disconnected sessions -.
Frankly, this is quite problematic and I do think such a set of future is
pretty useless, typically because when a client brutally disconnect, the server
will not be informed, and teh session will remain forever, unless you also
manage idling sessions (something you'll have to do anyway).
I don't know what your application is doing, but you have to have that in mind,
just in case.
> 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)
