hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-16744) Procedure V2 - Lock procedures to allow clients to acquire locks on tables/namespaces/regions
Date Wed, 11 Jan 2017 21:55:17 GMT

     [ https://issues.apache.org/jira/browse/HBASE-16744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-16744:
--------------------------
    Release Note: 
 Lock for HBase Entity either a Table, a Namespace, or Regions.

These are remote locks which live on master, and need periodic heartbeats to keep them alive.
(Once we request the lock, internally an heartbeat thread will be started). If master doesn't
receive the heartbeat in time, it'll release the lock and make it available to other users.

Use {@link LockServiceClient} to build instances. Then call {@link #requestLock()}. {@link
#requestLock} will contact master to queue the lock and start the heartbeat thread which will
check lock's status periodically and once the lock is acquired, it will send the heartbeats
to the master.

Use {@link #await} or {@link #await(long, TimeUnit)} to wait for the lock to be acquired.
Always call {@link #unlock()} irrespective of whether lock was acquired or not. If the lock
was acquired, it'll be released. If it was not acquired, it is possible that master grants
the lock in future and the heartbeat thread keeps it alive forever by sending heartbeats.
Calling {@link #unlock()} will stop the heartbeat thread and cancel the lock queued on master.

There are 4 ways in which these remote locks may be released/can be lost:
  * Call {@link #unlock}.
  * Lock times out on master: Can happen because of network issues, GC pauses, etc. Worker
thread will call the given abortable as soon as it detects such a situation. Fail to contact
master: If worker thread can not contact mater and thus fails to send heartbeat before the
timeout expires, it assumes that lock is lost and calls the
 *     abortable.
Worker thread is interrupted.

Use example:

 EntityLock lock = lockServiceClient.*Lock(...., "exampled lock", abortable);
  lock.requestLock();
  ....
   ....can do other initializations here since lock is 'asynchronous'...
 ....
 if (lock.await(timeout)) {
    ....logic requiring mutual exclusion
  }
   lock.unlock();
 

  was:
Locks for table/namespace/regions. Use {@link LockServiceClient} to build instances.

These are remote locks which live on master, and need periodic heartbeats to keep them alive.
(Once we requested the lock, internally an heartbeat thread will be started). If master doesn't
receive the heartbeat in time, it'll release the lock and make it available to other users.

{@link #requestLock} will contact master to queue the lock and start the heartbeat thread
which'll check lock's status periodically and once the lock is acquired, it will send the
heartbeats to the master.

Use {@link #await} or {@link #await(long, TimeUnit)} to wait for the lock to be acquired.
Always call {@link #unlock()} irrespective of whether lock was acquired or not. If the lock
was acquired, it'll be released. If it was not acquired, it's possible that master grants
the lock in future and the heartbeat thread keeps it alive forever by sending heartbeats.
Calling {@link #unlock()} will stop the heartbeat thread and cancel the lock queued on master.

There are 4 ways in which these remote locks may be released/can be lost:
  * Call {@link #unlock}.
  * Lock times out on master: Can happen because of network issues, GC pauses, etc.
  * Worker thread will call the given abortable as soon as it detects such a situation.
  * Fail to contact master: If worker thread can not contact mater and thus fails to send
heartbeat before the timeout expires, it assumes that lock is lost and calls the abortable.
  * Worker thread is interrupted.
 
 Use example:
 <code>
 HBaseLock lock = admin.*Lock(...., "exampled lock", abortable);
 lock.queueLock();
 ....
 ....can do other initializations here since lock is 'asynchronous'...
 ....
 if (lock.await(timeout)) {
    ....logic requiring mutual exclusion
 }
 lock.unlock();
 </code>



> Procedure V2 - Lock procedures to allow clients to acquire locks on tables/namespaces/regions
> ---------------------------------------------------------------------------------------------
>
>                 Key: HBASE-16744
>                 URL: https://issues.apache.org/jira/browse/HBASE-16744
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Appy
>            Assignee: Matteo Bertozzi
>         Attachments: HBASE-16744.master.001.patch, HBASE-16744.master.002.patch, HBASE-16744.master.003.patch,
HBASE-16744.master.004.patch, HBASE-16744.master.005.patch, HBASE-16744.master.006.patch,
HBASE-16744.master.007.patch, HBASE-16744.master.008.patch, HBASE-16744.master.009.patch,
HBASE-16744.master.010.patch, HBASE-16744.master.011.patch, HBASE-16744.master.012.patch,
HBASE-16744.master.013.patch, HBASE-16744.master.014.patch, HBASE-16744.master.015.patch,
HBASE-16744.master.016.patch, HBASE-16744.master.017.patch
>
>
> Will help us get rid of ZK locks.
> Will be useful for external tools like hbck, future backup manager, etc.



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

Mime
View raw message