[
https://issues.apache.org/jira/browse/DIRMINA-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kohlsche updated DIRMINA-1027:
--------------------------------------
Description:
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
[DIRMINA-1019|https://issues.apache.org/jira/browse/DIRMINA-1019]
([commit|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)
was:
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)
> 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 [DIRMINA-1019|https://issues.apache.org/jira/browse/DIRMINA-1019]
> ([commit|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)
