mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Wicklow (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRMINA-1019) SslHandler flushScheduledEvents race condition
Date Wed, 15 Jun 2016 15:23:09 GMT

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

Carl Wicklow edited comment on DIRMINA-1019 at 6/15/16 3:22 PM:
----------------------------------------------------------------

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=SslHandler.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 !




was (Author: cwicklow):
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)

Mime
View raw message