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