Emmanuel Lécharny wrote:
Emmanuel,
The issue isn't related to any type of corruption of concurrent access
to the event queue.
Sorry, Jason, I reread your first mal carefully and you are most
certainly right.
can you create a JIRA and post your suggested fix ? This is the best way
to g
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
struct
[
https://issues.apache.org/jira/browse/DIRMINA-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Resch updated DIRMINA-779:
Attachment: ssl_reodering_fix.diff
This diff was created from Mina 1.1.7. In testing it has
: 2.0.0-RC1, 2.0.0-M6, 2.0.0-M5, 2.0.0-M4, 2.0.0-M3,
2.0.0-M2, 2.0.0-M1, 1.1.7
Reporter: Jason Resch
Fix For: 1.1.7
The code in question is the flushScheduledEvents() method in SSLHandler.java:
public void flushScheduledEvents() {
// Fire events only when no lock is
All,
I think I've discovered a bug in Mina's TLS code. While I encountered this bug
in Mina 1.1.7 it seems the same problem code exists in Mina 2.0. The code in
question is the flushScheduledEvents() method in SSLHandler.java:
public void flushScheduledEvents() {
// Fire events only when
