[
https://issues.apache.org/jira/browse/KUDU-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans resolved KUDU-406.
-------------------------------------
Resolution: Duplicate
Fix Version/s: n/a
Resolving as a duplicate of the newer KUDU-1521.
> [java client] TestKuduSession is flaky when testing for
> PleaseThrottleException
> -------------------------------------------------------------------------------
>
> Key: KUDU-406
> URL: https://issues.apache.org/jira/browse/KUDU-406
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: M4
> Reporter: Jean-Daniel Cryans
> Fix For: n/a
>
>
> From Adar:
> {noformat}
> This code:
> // Test sending edits too fast
> session.setFlushMode(KuduSession.FlushMode.AUTO_FLUSH_BACKGROUND);
> session.setMutationBufferSpace(10);
> // The buffer has a capacity of 10, we insert 21 rows, meaning we fill
> the first one,
> // force flush, fill a second one before the first one could come back,
> // and the 21st row will be sent back.
> boolean gotException = false;
> for (int i = 50; i < 71; i++) {
> try {
> session.apply(createInsert(i));
> } catch (PleaseThrottleException ex) {
> gotException = true;
> assertEquals(70, i);
> // Wait for the buffer to clear
> ex.getDeferred().join(DEFAULT_SLEEP);
> session.apply(ex.getFailedRpc());
> session.flush().join(DEFAULT_SLEEP);
> }
> }
> assertTrue(gotException); <--
> assertEquals(21, countInRange(50, 71));
> If the client is running particularly slowly, isn't it possible for the
> background flush to finish before the 11th (or possibly 21st) row is
> inserted? Then we won't throw a PleaseThrottleException.
> {noformat}
> It's indeed possible and it happened once. We need a way to block the
> background flushing from happening, maybe through mocking.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
