You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2014/11/24 22:15:12 UTC

[jira] [Created] (ACCUMULO-3364) Inconsistency between java and native map update within single mutation

Josh Elser created ACCUMULO-3364:
------------------------------------

             Summary: Inconsistency between java and native map update within single mutation
                 Key: ACCUMULO-3364
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3364
             Project: Accumulo
          Issue Type: Bug
          Components: tserver
    Affects Versions: 1.6.1
            Reporter: Josh Elser


Noticed the following when I was poking around with {{ExamplesIT#testStatsCombiner}}:

{code}
    String table = getUniqueNames(1)[0];
    c.tableOperations().create(table);
    is = new IteratorSetting(10, StatsCombiner.class);
    StatsCombiner.setCombineAllColumns(is, true);

    c.tableOperations().attachIterator(table, is);
    bw = c.createBatchWriter(table, bwc);
    Mutation m = new Mutation("foo");
    m.put("a", "b", "1");
    m.put("a", "b", "3");
    bw.addMutation(m);
    bw.flush();

    Iterator<Entry<Key,Value>> iter = c.createScanner(table, Authorizations.EMPTY).iterator();
    assertTrue("Iterator had no results", iter.hasNext());
    Entry<Key,Value> e = iter.next();
    assertEquals("Results ", "1,3,4,2", e.getValue().toString());
{code}

When run against the Java maps, the above succeeds as the test expects it to. However, this fails when the instance is using native maps.

Talked to [~kturner] about this, and he noted that the Java maps [use a one-up counter when performing updates|https://github.com/apache/accumulo/blob/1.6.1/server/tserver/src/main/java/org/apache/accumulo/tserver/InMemoryMap.java#L404] whereas it does not appear that the NativeMap does this.

The reason I got stuck on it is because I expected to see both updates because the StatsCombiner was running below the VersioningIterator, but I would only see a single Key-Value out of the scanner (a value of "3,3,3,1").

My gut reaction is that we should have the same semantics across both Java and Native maps, although I'm not sure which one is correct/expected yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)