Emmanuel,
The issue isn't related to any type of corruption of concurrent access
to the event queue. It is that events may be sent to the next filter in
the wrong order from the order in which they were received. For
instance, the application layer might have a large protocol message
structure, lets say a few MB. While SSL deals with small records,
around a few tens of KB. While each SSL record is decrypted and put on
the Queue in the right order, the code in flushScheduleEvents does not
synchronize around the point when things are removed from the queue and
sent to the next filter. Therefore this issue should still exist if the
latest code in trunk contains this in the flushScheduledEvents() method:
| while ((e = messageReceivedEventQueue.poll()) != null) {
e.nextFilter.messageReceived(session, e.data);
}|
If there is a context switch to another thread right after an event is
polled from the thread, the next thread will take the next event off the
queue and send it to the next filter before the first thread does. That
while loop must be synchronized.
This is recognized in the above comment for writing, by the fact that
when writing, improperly ordered data will cause bad record MAC errors,
but it the same issue applies for processing reads, only it will
manifest as a protocol decoding error in the higher-level application
protocol.
Looking at the last code from trunk, the problem code still exists:
http://svn.apache.org/repos/asf/mina/trunk/core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java
Ctrl+F for "flushScheduledEvents"
Jason
Emmanuel Lecharny wrote:
On 4/3/10 6:17 PM, Bernd Fondermann wrote:
Jason,
Thanks for your contribution!
Would you mind to open a JIRA bug report and attach the diff file to
it, checking the ASF license check box?
Not sure this is still an issue in trunk, as the SSL layer has been
totally rewritten é months ago (for instance, there is no more
...filter/support/... package). The filterWriteEventQueue data structure
is now a ConcurrentLinkedQueue and protected against concurrent accesses.
Can you give the trunk a try ?
Thanks !--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
