[
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:23 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).
We're now bumping into an issue that looks like it's due to this (DIRMINA-1019)
- 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=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 !
> 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)
