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

jpalacios commented on DIRMINA-1070:
------------------------------------

Hi [~elecharny],
Thank you for getting back to me. Let me provide a bit more context to my issue.

Our application can stream gigabytes of data to clients based on a single 
message. We need to ensure that at any given time only a certain amount of 
bytes are inflight for any given session. The one message / one response 
approach I don't think will work for us. Also, in my testing (at least with my 
implementation of {{IoFilter}} I see that {{messageSent}} is not called only 
for write requests created by our application. There are other protocol 
messages which are handled by MINA while our application is streaming which 
produce multiple writes. For instance in my testing I've seen 
{{org.apache.sshd.common.session.helpers.AbstractSession#handleNewKeys}} 
putting messages into the {{DefaultWriteRequestQueue}}.

Regards
Juan

> Avoid unbounded message queueing when sending large amounts of data to slow 
> clients
> -----------------------------------------------------------------------------------
>
>                 Key: DIRMINA-1070
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-1070
>             Project: MINA
>          Issue Type: New Feature
>          Components: Core
>            Reporter: jpalacios
>              Labels: stability
>
> Our application runs an Apache MINA server to provide SSH support. We are 
> seeing {{OutOfMemoryError}} s when certain clients establish a session with a 
> large {{Window}} size. Particularly clients like TortoiseGit (which uses 
> TortoisePlink which in turn seems to use Putty) use an initial window size of 
> 2GB. From heap dumps we can see that the {{DefaultWriteRequestQueue}} is 
> filling up with {{WriteRequest}} instances and taking up gigabytes of space 
> until the heap blows. 



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

Reply via email to