[
https://issues.apache.org/jira/browse/DIRMINA-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364369#comment-15364369
]
Maria Petridean edited comment on DIRMINA-1039 at 7/6/16 2:21 PM:
------------------------------------------------------------------
Hmm, I didn't think of this option. I could take a look to see if I can apply
this and how.
Still, if i don't misunderstand something, i think a change like the one I
described above could be applied to address this issue at it's root. I actually
have a patch (locally; tested) to mina-core, I could commit it on a branch for
example for you to review it. But until now I didn't find any code-contribution
guide....
was (Author: maria.petridean):
Hmm, I didn't think of this option. I could take a look to see if I can apply
this and how.
Still, if i don't misunderstand something, i think a change like the one I
described above could be applied to address this issue at it's root. I actually
have a patch (locally) to mina-core, I could commit it on a branch for example
for you to review it. But until now I didn't find any code-contribution
guide....
> Response messages queue up on the server side waiting to be written to
> socket, while the server continues to read more request messages, causing out
> of heap memory
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-1039
> URL: https://issues.apache.org/jira/browse/DIRMINA-1039
> Project: MINA
> Issue Type: Bug
> Components: Core
> Reporter: Maria Petridean
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> One case in which this bug reproduces is by using a client which generates a
> heavy request-load. The mina thread which processes both reads and writes -
> exits the write cycle after processing every empty marker (the WriteRequest
> which wraps an empty buffer, acting as a message marker). This will result in
> the thread resuming the read cycle, hence reading more client request
> messages. After a few minutes, the number of read messages is much larger
> than the number of written response messages, even though the responses are
> waiting in the queue, ready to be written to socket.
> To solve this, the sever shouldn't exit the write cycle after processing
> every marker WriteRequest. This way the ratio between the read and written
> messages will be more balanced; this will avoid the heap memory getting full
> and causing server degradation.
> Also, an improvement can be considered here to avoid using the same single
> thread for both reads and writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
