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
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 get
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
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 get this patch injected and the
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
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
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?
Thanks a lot,
Bernd
On Sat, Apr 3, 2010 at 17:10, Jason Resch jre...@cleversafe.com wrote:
All,
I think I've discovered a bug in Mina's TLS
