[
https://issues.apache.org/jira/browse/DIRMINA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146987#comment-16146987
]
Emmanuel Lecharny commented on DIRMINA-1070:
--------------------------------------------
This is just plain normal behaviour. You application must take care of a slow
client.
Basically, you should not send a new response unless the previous one has been
fully sent (ie, you've got a {{messageSent}} event).
Of course, it might be a bit limitating, so you can decide to wait a bit before
stopping sending new data to a slow client, but again, this is an application
decision, not a MINA decision.
All in all, here is what your application should do :
- when receiving a message, process it
- check that the previous message has been sent properly (or aborted, ie an
exception has been received) checking a flag in the session attributes
- if it's ok, write the response
- otherwise, deal with the issue (ie discard the request, stack the response up
to a limit your application would set, kill the session, etc)
Keep in mind that MINA is based on an asynchronous mechanism, so your session
is actually never blocked on write like a synchronous system would, so every
time you write something back to your client, it's either sent immediately to
the socket, or if this socket is already full, it's stacked in a queue for a
later processing (and this is the reason you see the memory being consumed fast
with slow readers).
> 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)
