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

Goldstein Lyor commented on SSHD-754:
-------------------------------------

I have not had time to really think about the scenario you presented, and 
nowadays it will take me a while to find some free time to review it. Please 
feel free to go ahead and publish a pull-request once you think you have a 
proposal in mind - it will be easier for us to review it and better understand 
the problem and its possible fix.

That being said, off the top of my head - I believe one can control the window 
size via properties and/or window-size SSH messages (don't remember offhand the 
exact message exchange). AFAIK, the window size mechanism provides a way to 
throttle the data rate, so maybe that can be a way to address this issue as 
well.

> OOM in sending data for channel
> -------------------------------
>
>                 Key: SSHD-754
>                 URL: https://issues.apache.org/jira/browse/SSHD-754
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>            Reporter: Eugene Petrenko
>
> I have an implementation of SSHD server with the library. It sends gigabytes 
> (e.g. 5GB) of data as command output. 
> Starting from Putty plink 0.68 (also includes plink 0.69) we started to have 
> OOM errors. Checking memory dumps shown the most of the memory is consumed 
> from the function
> org.apache.sshd.common.session.AbstractSession#writePacket(org.apache.sshd.common.util.buffer.Buffer)
> In the hprof I see thousands of PendingWriteFuture objects (btw, each holds a 
> reference to a logger instance). And those objects are only created from this 
> function. 
> It is clear the session is running through rekey. I see the kexState 
> indicating the progress. 
> Is there a way to artificially limit the sending queue, no matter if related 
> remote window allows sending that enormous amount of data? As of my 
> estimation, the window was reported to be around 1.5 GB or more. Maybe, such 
> huge window size was caused by an arithmetic overflow that is fixed on 
> SSHD-701



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to