mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Goldstein Lyor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-810) mina sshd 1.6.0, using as sftp server, run for about one month, found that there is too many ConcurrentHaspMap objects in Nio2Acceptor.
Date Sun, 18 Mar 2018 06:20:00 GMT

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

Goldstein Lyor commented on SSHD-810:
-------------------------------------

Your description is a little unclear - there are *3* maps in the hierarchy - one in the _Nio2Service_,
one in _Nio2Session_ and the other in the _Nio2Acceptor_ - and *2* of them are {{ConcurrentHashMap}}
- the ones in the _Nio2Service_ and  _Nio2Acceptor_ (the one on the _Nio2Session_ is a simple
_HashMap_). However your description somehow refers to the _NioSession_ instead of the _Nio2Acceptor_
and/or _Nio2Service_ which may be the one supposedly "leaking":
{quote}
close and destory the Nio2Session
{quote}
so I am not sure how that would help (even assuming there is a leak as you claim). However,
to answer your question - the {{Session}} interface (which both _ClientSession_ and _ServerSession_
implement) exposes {{IoSession getIoSession()}} - which will return the _Nio2Session_ instance
through which the SSH session was created. *Caveat emptor:* you must ask:
{code:java}
Session sshSession = ...your session...
IoSession ioSession = sshSession.getIoSession();
if (ioSession instanceof Nio2Session) {
    ..do whatever you think will fix the problem...
}
{code}
since there are (at least) *2* implementations of {{IoSession}} - only one of which is _Nio2Session_
(the other being _MinaSession_). Some inspection of the _Nio2Acceptor_ code does not reveal
any reason for its associated map to grow beyond a few entries - unless you do lots of port
forwarding - which does not seem to be the case since you mention only SFTP.

As far as
{quote}
close and destory the Nio2Session
{quote}
goes, there should be no need - the SSH session automatically closes the associated _IoSession_:
{code:java|title=AbstractSession}
    @Override
    protected Closeable getInnerCloseable() {
        return builder()
                .parallel(toString(), getServices())
                .close(getIoSession())
                .build();
    }
{code}

What I would like to suggest is the following:

# Try version 1.7 - it contains quite a few fixes - although I do not remember one specifically
related to such a "leak" it does contain some memory management improvements
# Clone, compile and try [the 1.7.1-SNAPSHOT version|https://github.com/apache/mina-sshd]
- it also contains a few more memory management fixes/improvements.
# Open the DEBUG/TRACE levels of the _Nio2Session_, _Nio2Acceptor_ classes and try to figure
out whether all open sessions are closed (eventually).

> mina sshd 1.6.0, using as sftp server, run for about one month, found that there is too
many ConcurrentHaspMap  objects in Nio2Acceptor.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SSHD-810
>                 URL: https://issues.apache.org/jira/browse/SSHD-810
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 1.6.0
>            Reporter: young_shaw
>            Priority: Blocker
>              Labels: memleak, sshd
>         Attachments: memleak2.png
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> For example, the instance of "org.apache.sshd.common.io.nio2.Nio2Acceptor" which adress
is "0x732137c40" occupies 2,224,510,720 (71.65%) bytes.Its memory is mainly accumulated by
the instance of "java.util.concurrent.ConcurrentHashMap$Node[]" "0x744a55fb8" loaded by the
class "bootstrap class loader".
> I am wondering where can I close and destory the Nio2Session. Please help me, thank you.
> !memleak2.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message