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
HBase >> mail # dev >> StoreScanner created for memstore flush should be bothered about updated readers?


Copy link to this message
-
Re: StoreScanner created for memstore flush should be bothered about updated readers?
It seems you are right. I think only if a concurrent compaction finishes
the memstore scanner would be affected right?

How big is the affect for resetting the KVHeap ?

Enis
On Thu, Jan 30, 2014 at 11:48 AM, ramkrishna vasudevan <
[EMAIL PROTECTED]> wrote:

> Hi All
>
> In case of flush we create a memstore flusher which in turn creates a
>  StoreScanner backed by a Single ton MemstoreScanner.
>
> But this scanner also registers for any updates in the reader in the
> HStore.  Is this needed?
> If this happens then any update on the reader may nullify the current heap
> and the entire Scanner Stack is reset, but this time with the other
> scanners for all the files that satisfies the last top key.  So the flush
> that happens on the memstore holds the storefile scanners also in the heap
> that was recreated but originally the intention was to create a scanner on
> the memstore alone.
>
> Am i missing something here?  Or what i observed is right?  If so, then I
> feel that this step can be avoided.
>
> Regards
> Ram
>

 
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