All, thanks again for your feedback. I just consolidated some of these
learnings with some code samples here.
http://www.mammothdatallc.com/blog/accumulo-in-depth-look-at-filters-combiners-iterators-against-complex-values/
Best,
-Mike
On Fri, Jul 18, 2014 at 11:54 AM, William Slacum
I set up debugging and am rethrowing the exception. What's strange is it
appears that despite the iterator instance being properly set to
iterator.Counter (my implementation), my breakpoints aren't being hit, only
in the parent classes (Wrapping Iterator) and (SortedKeyValueIterator).
I have two
Herp... serves me right for not setting up a proper test case.
I think you need to override seek as well:
@Override
public void seek(...) throws IOException {
super.seek(...);
next();
}
I think I just realized the wrapping iterator could use some clean up,
because this isn't obvious.
That worked ;) - Thanks!
What a journey...
I like Accumulo's architecture and promise, but the difficulty in querying
it (lack of documentation, conventions) is a major concern and I'd imagine
has to have an impact on adoption. I'm curious if there have been any
conversations around changing the
There's been some mention about a desire to rethink the Iterator
interface as it has some deficiencies (notably the lack of a cleanup
before the iterators are torn down), but no one has stated that they're
actively working on this.
Getting better documentation wrt to convetions: let us know
Hi, All.
I'm curious what the best practices are around persisting complex
types/data in Accumulo (and aggregating on fields within them).
Let's say I have (row, column family, column qualifier, value):
A foo MyHugeAvroObject(count=2)
A foo MyHugeAvroObject(count=3)
Let's say MyHugeAvroObject
Hi Mike!
The Combiner interface is only for aggregating keys within a single row.
You can probably get away with implementing your combining logic in a
WrappingIterator that reads across all the rows in a given tablet.
To do some combine/fold/reduce operation, Accumulo needs the input type to
be
For a bit of psuedocode, I'd probably make a class that did something akin
to: http://pastebin.com/pKqAeeCR
I wrote that up real quick in a text editor-- it won't compile or anything,
but should point you in the right direction.
On Mon, Jul 14, 2014 at 3:44 PM, William Slacum
Thanks, William. I was just hitting you up for an example :)
I adapted your pseudocode (http://pastebin.com/ufPJq0g3), but noticed that
this.source in your example didn't have visibility. Did I worked around
it correctly?
When I add my iterator to my table and run scan from the shell, it returns
Ah, an artifact of me just willy nilly writing an iterator :) Any reference
to `this.source` should be replaced with `this.getSource()`. In `next()`,
your workaround ends up calling `this.hasTop()` as the while loop
condition. It will always return false because two lines up we set
`top_key` to
Hmm...Still doesn't return anything from the shell.
http://pastebin.com/ndRhspf8
Any thoughts? What's the best way to debug these?
On Mon, Jul 14, 2014 at 5:14 PM, William Slacum
wilhelm.von.cl...@accumulo.net wrote:
Ah, an artifact of me just willy nilly writing an iterator :) Any
A quick sanity check is to make sure you have data in the table and that
you can read the data without your iterator (I've thought I had a bug
because I didn't have proper visibilities more times than I'd like to
admit).
Alternatively, you can also enable remote-debugging via Eclipse into the
Anything in your Tserver log? I think you should just rethrow that
IOExcepton on your source's next() method, since they're usually not
recoverable (ie, just make Counter#next throw IOException)
On Mon, Jul 14, 2014 at 5:48 PM, Josh Elser josh.el...@gmail.com wrote:
A quick sanity check is to
13 matches
Mail list logo
