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

Goldstein Lyor commented on SSHD-854:
-------------------------------------

Hi [~jpalacios], after reviewing the issue's comments more thoroughly, I 
observed that the SSHD version in use is quite old (1.7.0). Since then, there 
have been many significant changes (hopefully improvements...) - including to 
the session management cycle. I would like to ask you to try to reproduce the 
issue with the latest released version (2.1.0).

Please see also the [section dealing with IOServiceFactory 
selection|https://github.com/apache/mina-sshd#selecting-an-ioservicefactoryfactory]
 and note that by default, we started using the *built-in* NIO2 factory. If you 
cannot reproduce it with NIO2, see if you can reproduce it with MINA - that may 
provide us a better understanding of where there might be an issue (or not...)

> 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)

Reply via email to