[
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)
