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 Threaded View
Blur >> mail # dev >> Re: [incubator-blur] The new Adhoc command is working though there are a few things hard coded that need to be pulled into the API. (753ab41)


Copy link to this message
-
Re: [incubator-blur] The new Adhoc command is working though there are a few things hard coded that need to be pulled into the API. (753ab41)
So been messing with the MR style api a little more and I don't really like
it.  The difference of having multiple things running in the JVM vs
independent turns out to be a reasonable enough difference that introduces
a whole lot of 'well we could do...' talk.

So instead how about a middle ground.  I still like the concept of a
BlurContext as it gives us an entry point to bail out of code using the
existing AtomicBoolean jazz with the progress() method. We could provide a
few types of BlurContexts, one that hard timed out after a set time, one
that had a time limit per BlurIndex, and another that had a timeout for
inactivity (think rt write Commands with no data coming in). We also get
the counters, always nice, and I'd like to see us move to parameter
retrieval like MR does with the context.getConf().getxxx() style vs the
Object[].  Unless someone has a really good reason as to wanting to keep
Object arrays??

Thoughts?

I can update the wiki to give a cleaner example if anyone thinks thats a
good idea?

~Garrett
On Fri, Aug 1, 2014 at 7:24 PM, Garrett Barton <[EMAIL PROTECTED]>
wrote:
 
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