[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674584#comment-16674584
]
jpalacios commented on SSHD-854:
--------------------------------
[~elecharny],
Do you think it's possible that the other half of the issue I'm seeing is a
more severe case of
[DIRMINA-1042|https://issues.apache.org/jira/browse/DIRMINA-1042]? The symptoms
certainly seem to match perfectly. I am also seeing the leak happening through
{{EPollSelectorImpl.fdToKey}} which doesn't get cleaned up when closing the
selector.
Looks like the fix was to add a retry logic so that the selector won't be
replaced so frequently. However that should still allow for the issue to affect
a system in a more extreme scenario, is that correct?
I'm not sure though that, as suggested in the ticket, closing the key will help
either as something would need to call `select` to eventually trigger the
`processDeregisterQueue` logic that will deal with the `cancelledKeys`.
I'd appreciate your thoughts.
Regards
Juan Palacios
> Massive object graph in NioSocketSession
> ----------------------------------------
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
> Reporter: jpalacios
> Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
