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

["Carl Wicklow (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRMINA-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15331909#comment-15331909 ] 

Carl Wicklow commented on DIRMINA-1019:
---------------------------------------

We've just updated to Mina 2.0.13 (prompted by SSL re-ordering data, as fixed by https://issues.apache.org/jira/browse/DIRMINA-779).

I'm not bumping into an issue that looks like it's due to this (DIRMINA-1019) - this fix works, but our application can (rarely) stall - I see the data come off the network, it goes up the filter chain into the SslFilter, but never goes up further.

I have a workaround (we send a ping down the session to flush things through), but thought I'd check if you folks thought it was an application issue or a Mina issue.

Here's roughly what I see in SslHandler.flushScheduledEvents() :

{code:title=Bar.java|borderStyle=solid}
	void flushScheduledEvents() {
		
        scheduled_events.incrementAndGet();

        if (sslLock.tryLock()) {
            
            try {
                do {
                	IoFilterEvent event;
                    
                    // ... and so on ....
                	
                } while (scheduled_events.decrementAndGet() > 0);
                
                // Time passes ... 
                
            } finally {
            	
            	// ... and, maybe, another thread incremented the scheduled_event count
            	
                sslLock.unlock();
            }
        }
        
        // If no more data is sent or received, we may leave here with unflushed events. 
    }
{code}

Sorry, no test case or fix !



> 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.13
>
>         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)