Ok. That one that I know of doesn't spin up a batch scanner, it makes a call to another program.
-----Original Message----- From: William Slacum [mailto:wilhelm.von.cl...@accumulo.net] Sent: Monday, January 28, 2013 7:33 PM To: dev@accumulo.apache.org Subject: Re: Accumulo 1.6 and beyond feature summit Currently it's not recommended to launch a batch scanner from an iterator and retrieve new information, due to the possibility of a dead lock. Other services may alleviate that concern, but due to lifecycle management issues (related to the "add a clean up method to iterators"), it's not fool proof to clean up connections from it. On Mon, Jan 28, 2013 at 7:21 PM, Dave Marion <dlmar...@comcast.net> wrote: > "- Allowing iterators to launch connections to other services > (caching, other tservers) to retrieve or write data" > > What does allow mean in this context? I don't think its disallowed > (I know of an iterator that does this). > > -----Original Message----- > From: William Slacum [mailto:wilhelm.von.cl...@accumulo.net] > Sent: Monday, January 28, 2013 7:13 PM > To: dev@accumulo.apache.org > Subject: Re: Accumulo 1.6 and beyond feature summit > > I'd like to see: > > - Data triggers on insertion > - REST interface for looking up ranges of keys > - A DSL or some other interpreted language for crafting iterators > - there's the clojure iterator, but something like python (via > jython) or javascript (via rhino) would be more adoptable > - Adding a clean up hook to iterators > - Allowing iterators to launch connections to other services (caching, > other > tservers) to retrieve or write data > - Merging of the batch scanner and scanner implementations > - a batch scanner with 1 thread have the same behavior as a scanner > - scanners have a close() method on them > - Adding some builder interface for creating and introspecting > iterator stacks > - Clients being able to scan to specific keys using the scan command > >
