mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRMINA-1027) SSLHandler writes corrupt messages under heavy load
Date Thu, 04 Feb 2016 22:15:39 GMT

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

Emmanuel Lecharny edited comment on DIRMINA-1027 at 2/4/16 10:15 PM:
---------------------------------------------------------------------

I think I have applied the patch in the 2.0 branch, so the next release (and even 2.0.11)
should be ok. Can you confirm that ? (or test the 2.0.12 whichis available on people.apache.org/~elecharny)


was (Author: elecharny):
I think I have applied the patch in the 2.0 branch, so the next release (and even 2.0.11)
should be ok. Can you confirm that ?

> SSLHandler writes corrupt messages under heavy load
> ---------------------------------------------------
>
>                 Key: DIRMINA-1027
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-1027
>             Project: MINA
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 2.0.11
>            Reporter: Michael Kohlsche
>            Priority: Critical
>
> I’m facing a critical problem in my project with an MINA-stack including SSL. My Protocol-IoFilterAdapter
receives corrupt messages under heavy load (JMeter-Benchmark with 300 Threads and round about
5-10 MINA-calls per thread). The Problem disappeared without SSL, so I debugged for some days,
and I think the problem occurred because of the changes made for fixing the issue https://issues.apache.org/jira/browse/DIRMINA-1019
(http://git-wip-us.apache.org/repos/asf/mina/commit/9b5c07f9). I think the problem is that
the SSLHandler is calling messageReceived while also writing data into the next filter, which
is writing inside the messageReceivedEventQueue. With the fix provided inside the race-condition-ticket,
it works like a charm. So I think that the answer of the question "Why the second loop is
also protected by the loop?" is: because otherwise the messageReceivedEventQueue is gets corrupted
data...
> (I hope I’m not wrong and anybody can follow my thoughts and maybe bad English xD)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message