[
https://issues.apache.org/jira/browse/KUDU-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142264#comment-16142264
]
Jean-Daniel Cryans commented on KUDU-1544:
------------------------------------------
[~danburkert] [~adar] is this still a thing?
> 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
>
> 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)
