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

Matteo Bertozzi commented on HBASE-8310:
----------------------------------------

If I understood correctly the explanation of Enis, this is not a problem on the 
lock or snapshots.

This seems more a semantic problem on the client...
{quote}Still this would contradict the synchronized purpose of the client 
snapshot request?{quote}
This is a problem with the current client, that will be solved with the next 
async version and the possibility to cancel tasks. On the client side now 
there's a timeout to avoid to lock the user.. but there's no guarantee that the 
operation is aborted/finished. If you take a look at the messages e.g. 
isTableEnabled() you get something like "Table not yet enabled, after %d ms".

NOTE that snapshot (in contrast with other operations, e.g. isTableEnabled) has 
a HBaseAdmin.isSnapshotFinished()... this means that if you get the "wasn't 
completed in expectedTime" message you can wait loop on isSnapshotFinished()
                
> HBase snapshot timeout default values and TableLockManger timeout
> -----------------------------------------------------------------
>
>                 Key: HBASE-8310
>                 URL: https://issues.apache.org/jira/browse/HBASE-8310
>             Project: HBase
>          Issue Type: Bug
>          Components: snapshots
>    Affects Versions: 0.95.0
>            Reporter: Jerry He
>            Assignee: Jerry He
>            Priority: Minor
>             Fix For: 0.98.0, 0.95.2, 0.94.9
>
>
> There are a few timeout values and defaults being used by HBase snapshot.
> DEFAULT_MAX_WAIT_TIME (60000 milli sec, 1 min) for client response
> TIMEOUT_MILLIS_DEFAULT (60000 milli sec, 1 min) for Procedure timeout
> SNAPSHOT_TIMEOUT_MILLIS_DEFAULT (60000 milli sec, 1 min) for region server 
> subprocedure  
> There is also other timeout involved, for example, 
> DEFAULT_TABLE_WRITE_LOCK_TIMEOUT_MS (10 mins) for 
> TakeSnapshotHandler#prepare()
> We could have this case:
> The user issues a sync snapshot request, waits for 1 min, and gets an 
> exception.
> In the meantime the snapshot handler is blocked on the table lock, and the 
> snapshot may continue to finish after 10 mins.
> But the user will probably re-issue the snapshot request during the 10 mins.
> This is a little confusing and messy when this happens.
> To be more reasonable, we should either increase the DEFAULT_MAX_WAIT_TIME or 
> decrease the table lock waiting time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to