accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ACCUMULO-3364) Inconsistency between java and native map update within single mutation
Date Mon, 24 Nov 2014 21:15:12 GMT
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)

Mime
View raw message