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

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

bq.Do you know if Phoenix still has access to memstore size?
Ya it is possible to get what that part of code wants. 
If the wait op is been interrupted, we do Thread.currentThread().interrupt(); 
again.
bq.Could we get a documentation update that tells me, as a consumer, what 
happens if the timeout is exceeded? (should be an InterruptedException, 
right?). Should Region#waitForFlushes(long) throws InterruptedException?
No.. it wont throw InterruptedException.  It is not an interruption case.  I 
was trying to follow same way as that of Object.wait(timeout).  If within time 
out notify happens, we come out of wait then. Or else at timeout time. But no 
Exception.  So for which condition we were waiting, the callee is supposed to 
check that condition again once out of wait.    But here it is bit diff case as 
we were waiting for flushes.  We dont have any API to know whether flush is 
ongoing or not.  For Phoenix case, it is the memstore size check which is fine. 
 But here I think it would be better to return a boolean indicating whether it 
is flushes over or not.  Sounds good?

> Provide Region#waitForFlushes API
> ---------------------------------
>
>                 Key: HBASE-18906
>                 URL: https://issues.apache.org/jira/browse/HBASE-18906
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Coprocessors
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0-alpha-4
>
>         Attachments: HBASE-18906.patch
>
>
> Expose an API for the CPs to wait for all on going flushes in a Region. The 
> API should support taking a time out.
> Background
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to