[jira] [Created] (DIRMINA-1019) SslHandler flushScheduledEvents race condition

["Terence Marks (JIRA)" <ji...@apache.org>]

Terence Marks created DIRMINA-1019:
--------------------------------------

             Summary: SslHandler flushScheduledEvents race condition
                 Key: DIRMINA-1019
                 URL: https://issues.apache.org/jira/browse/DIRMINA-1019
             Project: MINA
          Issue Type: Bug
          Components: SSL
    Affects Versions: 2.0.9
            Reporter: Terence Marks
             Fix For: 2.0.10


>From what I've seen, the SslFilter class schedules events onto the SslHandler and then flushes them via the SslHandler.flushScheduledEvents() method.

Within SslHandler.flushScheduledEvents() the lock can only be accumulated by a single thread, and all other threads that try to accumulate the lock instead follow through and not block waiting to get the lock.

...
if (sslLock.tryLock()) {
...

This leads to the race condition where a thread may call SslHandler.scheduleFilterWrite() followed by SslHandler.flushScheduledEvents() while another thread holds the sslLock and has finished dequeuing the SslHandler.filterWriteEventQueue and is currently dequeuing the SslHandler.messageReceivedEventQueue.

I've actually hit this race condition quite a few times today and have added in a small fix which essentially tracks the number of times SslHandler.flushScheduledEvents() has been called. There's probably a much better solution but yeah just letting you guys know what I've found.

Thanks,
Terence



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