[ 
https://issues.apache.org/jira/browse/HBASE-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15567511#comment-15567511
 ] 

Anoop Sam John commented on HBASE-16799:
----------------------------------------

Came across this while I was working on HBASE-16747. I had to change signature 
of APIs in Store and saw it is CP exposed. That made me to think this way. 
bq.We need to add a warning on the Store API?
You mean on other APIs which will be there after this patch?  Ya I will add 
comments in Store interface not to expose APIs that change the state of the 
store.  Also any Store impl that we make have to extend HStore not directly 
impl this interface. That might happen very very rare. We have HMobStore which 
is any way extending HStore.

> CP exposed Store should not expose unwanted APIs 
> -------------------------------------------------
>
>                 Key: HBASE-16799
>                 URL: https://issues.apache.org/jira/browse/HBASE-16799
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0
>
>         Attachments: HBASE-16799.patch, HBASE-16799.patch, 
> HBASE-16799_V2.patch
>
>
> Store is exposed to CPs. The main use cases I can think of are getting store 
> scanner and other getters which return different states like memstore size, 
> max seqId etc. Those make sense.
> But we added many other APIs which changes the state of the memstore, bulk 
> load files etc into this interface.  Even an API which expose the memstore 
> itself!.  This allow adding mutations into memstore bypassing all steps in 
> region. We track the memstore size per region level as well as globally. 
> These only allow us to flush region at sizes and/or flush selected regions 
> because of global heap pressure. Now if a CP get hold of store and/or 
> memstore, it can add mutations with out knowledge of these size accounting 
> and possibly OOME the RS.  Similar way the bulk load related APIs. At HRegion 
> level, there are steps done (WAL write etc) after the bulk load HFile on 
> store. So bypassing these wont be correct.
> In this jira, plan is to remove all such leaked APIs from Store. They are 
> called from HRegion and we can type cast to HStore to call them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to