[
https://issues.apache.org/jira/browse/KUDU-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Burkert updated KUDU-1544:
------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0
Status: Resolved (was: In Review)
https://github.com/apache/kudu/commit/3cd95f190f286b64b9b68f0fd3c925fd79bdcae9
> Race in Java client's AsyncKuduSession.apply()
> ----------------------------------------------
>
> Key: KUDU-1544
> URL: https://issues.apache.org/jira/browse/KUDU-1544
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: 0.10.0
> Reporter: Adar Dembo
> Fix For: 1.5.0
>
>
> The race is between calls to flushNotification.get() and
> inactiveBufferAvailable(). Suppose T1 calls inactiveBufferAvailable(), gets
> back false, but is descheduled before constructing a PleaseThrottleException.
> Now T2 is scheduled, finishes an outstanding flush, calls queueBuffer(), and
> resets flushNotification to an empty Deferred. When T1 is rescheduled, it
> throws a PTE with that empty Deferred.
> What is the effect? If the user waits on the Deferred from the PTE, the user
> is effectively waiting on "the next flush", which, depending on the stream of
> operations, may take place soon, may not take place for some time, or may not
> take place at all.
> To fix this, we should probably reorder the calls to flushNotification.get()
> in apply() to happen before calls to inactiveBufferAvailable(). That way, a
> race will yield a stale Deferred rather than an empty one, and waiting on the
> stale Deferred should be a no-op.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
