mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jpalacios (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
Date Mon, 05 Nov 2018 10:30:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674925#comment-16674925

jpalacios commented on SSHD-854:


Yes, the keys are deregistered but in the {{EPollSelectorImpl}} this *does not include* removing
them from its {{fdToKey}} map. As a result if the {{EPollSelectorImpl}} is still referenced
somewhere in the heap the keys are retained and they reference sessions which reference other
selectors which reference other keys...and the heap blows.

I think the same was suggested by the reporter of [DIRMINA-1042|https://issues.apache.org/jira/browse/DIRMINA-1042]
in the descriptor.

The SelectionKeyImpl in the fdToKey HashMap of the EPollSelectorImpl don't get remove.

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

View raw message