Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> IteratorSetting validate options?


+
Christopher 2013-01-11, 17:39
Copy link to this message
-
Re: IteratorSetting validate options?
On Fri, Jan 11, 2013 at 12:39 PM, Christopher <[EMAIL PROTECTED]> wrote:
> Would it make sense to require IteratorSettings to validate options by
> passing the options to the class when they are set? This could be useful
> for fast failure on things like: invalid number of versions set on the
> VersioningIterator.
>
> However, right now, IteratorSettings does not assume we have the class we
> are configuring available on the classpath at the moment it is constructed.
> It currently has a constructor that accepts fully-qualified class names as
> an argument, and carries it as a string throughout its lifecycle. To get
> fast failure, we'd have to get rid of that, and only allow Iterators to be
> specified by their Class, and then we could instantiate the class and call
> "validateOption(key, value)" or something similar.

I do not like making the client have the class they are trying to
configure for a server on their classpath.  There is a thrift method
that client can call on any tablet server to see if the server has a
particular class.   This model could be extended to support checking
config.

>
> Thoughts?
>
> P.S.
> On a related note- I was thinking that we're starting to develop this
> pattern of carrying configuration in objects for different component
> classes (Iterators via IteratorSettings, BatchWriters via
> BatchWriterConfig, etc.), and then we have per-table and
> tserver/master/gc/etc.-specific configuration). It seems like we should
> start thinking about more generic ways of doing this, that's still useful
> to the respective APIs (I'd hate to pass around Properties objects, or a
> Map<String,String> to everything).
I agree.  Configuring an accumulo client outside of java code can be
cumbersome.  It would be nice if I could pass some sort of config file
to the Connector that would configure all of the knobs on the client.
Open a ticket for 1.6

>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB