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

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny resolved DIRMINA-1019.
----------------------------------------
    Resolution: Fixed

Should be fixed with http://git-wip-us.apache.org/repos/asf/mina/commit/9b5c07f9

> 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
>
>         Attachments: SslFilterTest.java, fix.java
>
>
> 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)