[jira] [Commented] (HBASE-5487) Generic framework for Master-coordinated tasks
[ https://issues.apache.org/jira/browse/HBASE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245829#comment-13245829 ] Mubarak Seyed commented on HBASE-5487: -- @Enis I am not working on this right now. Thanks. Generic framework for Master-coordinated tasks -- Key: HBASE-5487 URL: https://issues.apache.org/jira/browse/HBASE-5487 Project: HBase Issue Type: New Feature Components: master, regionserver, zookeeper Affects Versions: 0.94.0 Reporter: Mubarak Seyed Labels: noob Need a framework to execute master-coordinated tasks in a fault-tolerant manner. Master-coordinated tasks such as online-scheme change and delete-range (deleting region(s) based on start/end key) can make use of this framework. The advantages of framework are 1. Eliminate repeated code in Master, ZooKeeper tracker and Region-server for master-coordinated tasks 2. Ability to abstract the common functions across Master - ZK and RS - ZK 3. Easy to plugin new master-coordinated tasks without adding code to core components -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5675) Create table fails if we keep refreshing master's UI for task monitor status
[
https://issues.apache.org/jira/browse/HBASE-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241471#comment-13241471
]
Mubarak Seyed commented on HBASE-5675:
--
I could create a table using workarounds
# Increase the RPC timeout value to 10 minutes
# Create one table at a time
# No refresh of master's web UI
Create table fails if we keep refreshing master's UI for task monitor status
Key: HBASE-5675
URL: https://issues.apache.org/jira/browse/HBASE-5675
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.90.4
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Labels: noob
I tried to create a table with 2K pre-split regions, region assignment was in
middle and i was keep refreshing master's web UI to find the status of the
task using task monitor, table creation was failed and {{META}} was showing
2K regions with server location value is {{null}} and regions weren't
deployed onto region-servers.
{code}
table_ACreating table table_A
java.io.IOException: java.io.IOException:
java.util.ConcurrentModificationException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95)
at
org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:384)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:294)
at com.test.tools.hbase.schema.createIfNotExists(schema.java:520)
at com.test.tools.hbase.schema.main(schema.java:627)
Caused by: org.apache.hadoop.ipc.RemoteException: java.io.IOException:
java.util.ConcurrentModificationException
at java.util.SubList.checkForComodification(AbstractList.java:752)
at java.util.SubList.add(AbstractList.java:632)
at java.util.SubList.add(AbstractList.java:633)
at java.util.SubList.add(AbstractList.java:633)
..
..
at java.util.SubList.add(AbstractList.java:633)
at java.util.AbstractList.add(AbstractList.java:91)
at
org.apache.hadoop.hbase.monitoring.TaskMonitor.createStatus(TaskMonitor.java:76)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:510)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:490)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:853)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:813)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:780)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)
at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:771)
at
org.apache.hadoop.hbase.ipc.HBaseRPC$Invoker.invoke(HBaseRPC.java:257)
at $Proxy5.createTable(Unknown Source)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:382)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5675) Create table fails if we keep refreshing master's UI for task monitor status
[
https://issues.apache.org/jira/browse/HBASE-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241513#comment-13241513
]
Mubarak Seyed commented on HBASE-5675:
--
@Lars
CDH3u2 backports distributed log splitting to 0.90.x branch and task monitor
stuff as well. I have verified the code
{code}
public ListStoreFile close(final boolean abort) throws IOException {
// Only allow one thread to close at a time. Serialize them so dual
// threads attempting to close will run up against each other.
MonitoredTask status = TaskMonitor.get().createStatus(
Closing region + this +
(abort ? due to abort : ));
status.setStatus(Waiting for close lock);
try {
synchronized (closeLock) {
return doClose(abort, status);
}
} finally {
status.cleanup();
}
}
{code}
It is affected in 0.92 and above i believe. Thanks.
Create table fails if we keep refreshing master's UI for task monitor status
Key: HBASE-5675
URL: https://issues.apache.org/jira/browse/HBASE-5675
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.90.4, 0.92.0, 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Labels: noob
I tried to create a table with 2K pre-split regions, region assignment was in
middle and i was keep refreshing master's web UI to find the status of the
task using task monitor, table creation was failed and {{META}} was showing
2K regions with server location value is {{null}} and regions weren't
deployed onto region-servers.
{code}
table_ACreating table table_A
java.io.IOException: java.io.IOException:
java.util.ConcurrentModificationException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95)
at
org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:384)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:294)
at com.test.tools.hbase.schema.createIfNotExists(schema.java:520)
at com.test.tools.hbase.schema.main(schema.java:627)
Caused by: org.apache.hadoop.ipc.RemoteException: java.io.IOException:
java.util.ConcurrentModificationException
at java.util.SubList.checkForComodification(AbstractList.java:752)
at java.util.SubList.add(AbstractList.java:632)
at java.util.SubList.add(AbstractList.java:633)
at java.util.SubList.add(AbstractList.java:633)
..
..
at java.util.SubList.add(AbstractList.java:633)
at java.util.AbstractList.add(AbstractList.java:91)
at
org.apache.hadoop.hbase.monitoring.TaskMonitor.createStatus(TaskMonitor.java:76)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:510)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:490)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:853)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:813)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:780)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)
at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:771)
at
org.apache.hadoop.hbase.ipc.HBaseRPC$Invoker.invoke(HBaseRPC.java:257)
at $Proxy5.createTable(Unknown Source)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:382)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5675) Create table fails if we keep refreshing master's UI for task monitor status
[
https://issues.apache.org/jira/browse/HBASE-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241877#comment-13241877
]
Mubarak Seyed commented on HBASE-5675:
--
Thanks Jon.
Create table fails if we keep refreshing master's UI for task monitor status
Key: HBASE-5675
URL: https://issues.apache.org/jira/browse/HBASE-5675
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.90.4, 0.92.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Labels: noob
I tried to create a table with 2K pre-split regions, region assignment was in
middle and i was keep refreshing master's web UI to find the status of the
task using task monitor, table creation was failed and {{META}} was showing
2K regions with server location value is {{null}} and regions weren't
deployed onto region-servers.
{code}
table_ACreating table table_A
java.io.IOException: java.io.IOException:
java.util.ConcurrentModificationException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95)
at
org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:384)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:294)
at com.test.tools.hbase.schema.createIfNotExists(schema.java:520)
at com.test.tools.hbase.schema.main(schema.java:627)
Caused by: org.apache.hadoop.ipc.RemoteException: java.io.IOException:
java.util.ConcurrentModificationException
at java.util.SubList.checkForComodification(AbstractList.java:752)
at java.util.SubList.add(AbstractList.java:632)
at java.util.SubList.add(AbstractList.java:633)
at java.util.SubList.add(AbstractList.java:633)
..
..
at java.util.SubList.add(AbstractList.java:633)
at java.util.AbstractList.add(AbstractList.java:91)
at
org.apache.hadoop.hbase.monitoring.TaskMonitor.createStatus(TaskMonitor.java:76)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:510)
at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:490)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:853)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:813)
at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:780)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)
at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:771)
at
org.apache.hadoop.hbase.ipc.HBaseRPC$Invoker.invoke(HBaseRPC.java:257)
at $Proxy5.createTable(Unknown Source)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:382)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234721#comment-13234721 ] Mubarak Seyed commented on HBASE-4991: -- Please close this one. Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.96.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234793#comment-13234793 ] Mubarak Seyed commented on HBASE-4720: -- I was expecting Andy to review the new patch. Once it is reviewed, i can pull back to 0.94.x. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.96.0 Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234946#comment-13234946
]
Mubarak Seyed commented on HBASE-5434:
--
Test failure @24/Feb/12 00:35 are not related to the patch.
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch, HBASE-5434.trunk.v2.patch,
HBASE-5434.trunk.v2.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5614) createTableAsync gets blocked and it is not an asynchronous operation
[
https://issues.apache.org/jira/browse/HBASE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235115#comment-13235115
]
Mubarak Seyed commented on HBASE-5614:
--
{{HBaseAdmin.createAsyncTable}} call from client to Master:
{code}
12/03/21 18:00:26 WARN zookeeper.ZKTable: Moving table table_A state to enabled
but was already enabled
12/03/21 18:00:26 INFO wal.HLog: HLog configuration: blocksize=128 MB,
rollsize=121.6 MB, enabled=true, optionallogflushinternal=1000ms
12/03/21 18:00:26 INFO wal.SequenceFileLogWriter: Using syncFs -- HDFS-200
12/03/21 18:00:26 INFO wal.HLog: New hlog
/hbase/root/table_A/6d3fe8aa7eae1c13b4ce5b54a13af1e0/.logs/hlog.1332352826075
12/03/21 18:00:26 INFO wal.HLog: Using getNumCurrentReplicas--HDFS-826
12/03/21 18:00:26 INFO regionserver.HRegion: Onlined
table_A,,1332352825867.6d3fe8aa7eae1c13b4ce5b54a13af1e0.; next sequenceid=1
12/03/21 18:00:26 INFO catalog.MetaEditor: Added 1 regions to META
12/03/21 18:00:26 INFO regionserver.HRegion: Closed
table_A,,1332352825867.6d3fe8aa7eae1c13b4ce5b54a13af1e0.
12/03/21 18:00:26 INFO regionserver.HRegion: Onlined
table_A,0015d867,1332352825873.ecf7c1e64eae49c396577e3156bc6555.; next
sequenceid=1
12/03/21 18:00:26 INFO regionserver.HRegion: Closed
table_A,0015d867,1332352825873.ecf7c1e64eae49c396577e3156bc6555.
{code}
After 5 minutes {{hbase.rpc.timeout}} value, master client channel gets
ClosedChannelException
{code}
12/03/21 18:05:28 WARN ipc.HBaseServer: IPC Server Responder, call
createTable({NAME = 'table_A', FAMILIES = [{NAME = 'CF1s', BLOOMFILTER =
'ROW', REPLICATION_SCOPE = '0', VERSIONS = '1', COMPRESSION = 'LZO', TTL =
'29870', BLOCKSIZE = '65536', IN_MEMORY = 'false', BLOCKCACHE =
'true'}]}, [[B@25a0504a) from 1.1.1.1:34981: output error
12/03/21 18:05:28 WARN ipc.HBaseServer: IPC Server handler 73 on 6 caught:
java.nio.channels.ClosedChannelException
at
sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:133)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at
org.apache.hadoop.hbase.ipc.HBaseServer.channelWrite(HBaseServer.java:1341)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Responder.processResponse(HBaseServer.java:727)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Responder.doRespond(HBaseServer.java:792)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1083)
{code}
{{AssignmentManager}} gets {{null}} value as server location
{code}
12/03/21 18:35:13 INFO master.AssignmentManager: Server null returned
java.lang.NullPointerException: Passed server is null for
6d3fe8aa7eae1c13b4ce5b54a13af1e0
12/03/21 18:35:13 INFO master.AssignmentManager: Server null returned
java.lang.NullPointerException: Passed server is null for
a47815dfcdf24f49e40f50b6fdd65dd9
12/03/21 18:35:13 INFO master.AssignmentManager: Server null returned
java.lang.NullPointerException: Passed server is null for
ecf7c1e64eae49c396577e3156bc6555
{code}
From master log, bulk assignment happens (100 regions at a time), i can
increase the value to 200 (or higher) but {{createTableAsync}} shouldn't get
blocked.
createTableAsync gets blocked and it is not an asynchronous operation
-
Key: HBASE-5614
URL: https://issues.apache.org/jira/browse/HBASE-5614
Project: HBase
Issue Type: Bug
Components: master, regionserver
Affects Versions: 0.90.4
Reporter: Mubarak Seyed
Labels: noob
I have created table A using {{HBaseAdmin.createTableAsync()}} with 2000
pre-split regions, the expectation was client RPC call does not get blocked
and i had only used 5 minutes as RPC socket timeout value.
It appears from logs/code that clients gets blocked (honoring the
{{hbase.rpc.timeout}} value), times out after 5 minutes, master nio channel
gets closed (related to client which invoked the createAsyncTable operation),
put region entries in inconsistent state in META, meaning {{info:server}} is
marked as null and AssignmentManager gets null server value (which causes
NPE) and causes to table creation fail, i could not succeed until changing
the {{hbase.rpc.timeout}} value to 15 minutes and created tables one at a
time (each table has more than 2K pre-split regions in it)
Please refer the logs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5614) createTableAsync gets blocked and it is not an asynchronous operation
[
https://issues.apache.org/jira/browse/HBASE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235202#comment-13235202
]
Mubarak Seyed commented on HBASE-5614:
--
@Gregory
I am working on it. Thanks.
createTableAsync gets blocked and it is not an asynchronous operation
-
Key: HBASE-5614
URL: https://issues.apache.org/jira/browse/HBASE-5614
Project: HBase
Issue Type: Bug
Components: master, regionserver
Affects Versions: 0.90.4
Reporter: Mubarak Seyed
Labels: noob
I have created table A using {{HBaseAdmin.createTableAsync()}} with 2000
pre-split regions, the expectation was client RPC call does not get blocked
and i had only used 5 minutes as RPC socket timeout value.
It appears from logs/code that clients gets blocked (honoring the
{{hbase.rpc.timeout}} value), times out after 5 minutes, master nio channel
gets closed (related to client which invoked the createAsyncTable operation),
put region entries in inconsistent state in META, meaning {{info:server}} is
marked as null and AssignmentManager gets null server value (which causes
NPE) and causes to table creation fail, i could not succeed until changing
the {{hbase.rpc.timeout}} value to 15 minutes and created tables one at a
time (each table has more than 2K pre-split regions in it)
Please refer the logs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220417#comment-13220417 ] Mubarak Seyed commented on HBASE-4991: -- @Stack bq. It might be time to kill this issue and start up a new one. Not under 5487 though. What you think Mubarak? I'd think that if we started a new issue, it'd be called online merge and would first work out the design. Fine, let us start a new issue and keep brainstorming on design (until get a logical point) Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220486#comment-13220486 ] Mubarak Seyed commented on HBASE-4991: -- [HBASE-5504|https://issues.apache.org/jira/browse/HBASE-5504] will be used for new design and brainstorming. Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5504) Online Merge
[
https://issues.apache.org/jira/browse/HBASE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220572#comment-13220572
]
Mubarak Seyed commented on HBASE-5504:
--
bq. What if the master crashes anywhere between step 6 and step 19 ? How would
the new master deal with the outstanding table lock ?
I think new active master (after failover) should resume executing task
(provided state is maintained in table lock znode)
Online Merge
Key: HBASE-5504
URL: https://issues.apache.org/jira/browse/HBASE-5504
Project: HBase
Issue Type: Brainstorming
Components: client, master, shell, zookeeper
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.96.0
As discussed, please refer the discussion at
[HBASE-4991|https://issues.apache.org/jira/browse/HBASE-4991]
Design suggestion from Stack:
{quote}
I suggest a design below. It has some prerequisites, some general function
that this feature could use (and others). The prereqs if you think them good,
could be done outside of this JIRA.
Here's a suggested rough outline of how I think this feature should run. The
feature I'm describing below is merge and deleteRegion for I see them as in
essence the same thing.
(C) Client, (M) Master, RS (Region server), ZK (ZooKeeper)
1. Client calls merge or deleteRegion API. API is a range of rows. (C)
2. Master gets call. (M)
3. Master obtains a write lock on table so it can't be disabled from under
us. The write lock will also disable splitting. This is one of the prereqs I
think. Its HBASE-5494 (Or we could just do something simpler where we have a
flag up in zk that splitRegion checks but thats less useful I think; OR we do
the dynamic configs issue and set splits to off via a config. change).
There'd be a timer for how long we wait on the table lock. (M - ZK)
4. If we get the lock, write intent to merge a range up into zk. It also
hoists into zk if its a pure merge or a merge that drops the region data (a
deleteRegion call) (M)
5. Return to the client either our failed attempt at locking the table or an
id of some sort used identifying this running operation; can use it querying
status. (M - C)
6. Turn off balancer. TODO/prereq: Do it in a way that is persisted. Balancer
switch currently in memory only so if master crashes, new master will come up
in balancing mode # (If we had dynamic config. could hoist up to zk a config.
that disables the balancer rather than have a balancer-specific flag/znode OR
if a write lock outstanding on a table, then the balancer does not balance
regions in the locked table - this latter might be the easiest to do) (M)
7. Write into zk that just turned off the balancer (If it was on) (M - ZK)
8. Get regions that are involved in the span (M)
9. Hoist the list up into zk. (M - ZK)
10. Create region to span the range. (M)
11. Write that we did this up into zk. (M - ZK)
12. Close regions in parallel. Confirm close in parallel. (M - RS)
13. Write up into zk regions closed (This might not be necessary since can
ask if region is open). (M - ZK)
14. If a merge and not a delete region, move files under new region. Might
multithread this (moves should go pretty fast). If a deleteregion, we skip
this step. (M)
15. On completion mark zk (though may not be necessary since its easy to look
in fs to see state of move). (M - ZK)
16. Edit .META. (M)
17. Confirm edits went in. (M)
18. Move old regions to hbase trash folder TODO: There is no trash folder
under /hbase currently. We should add one. (M)
19. Enable balancer (if it was off) (M)
20. Unlock table (M)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time
[ https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220585#comment-13220585 ] Mubarak Seyed commented on HBASE-5494: -- We can store zookeeper.znode.parent/locks/table_name and data could be txId (lock held by a transaction id) Mode (W or R) State Introduce a zk hosted table-wide read/write lock so only one table operation at a time -- Key: HBASE-5494 URL: https://issues.apache.org/jira/browse/HBASE-5494 Project: HBase Issue Type: Improvement Reporter: stack I saw this facility over in the accumulo code base. Currently we just try to sort out the mess when splits come in during an online schema edit; somehow we figure we can figure all possible region transition combinations and make the right call. We could try and narrow the number of combinations by taking out a zk table lock when doing table operations. For example, on split or merge, we could take a read-only lock meaning the table can't be disabled while these are running. We could then take a write only lock if we want to ensure the table doesn't change while disabling or enabling process is happening. Shouldn't be too hard to add. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5504) Online Merge
[
https://issues.apache.org/jira/browse/HBASE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220596#comment-13220596
]
Mubarak Seyed commented on HBASE-5504:
--
How do we get around if merge/delete-range get stuck (it should not but if it
happens???), can we provide a tool to fail or delete? (something like admin
operation). User can delete the lock znode in ZK (thats the worst case)? Can we
make use of [HBASE-5459|https://issues.apache.org/jira/browse/HBASE-5459]?
Online Merge
Key: HBASE-5504
URL: https://issues.apache.org/jira/browse/HBASE-5504
Project: HBase
Issue Type: Brainstorming
Components: client, master, shell, zookeeper
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.96.0
As discussed, please refer the discussion at
[HBASE-4991|https://issues.apache.org/jira/browse/HBASE-4991]
Design suggestion from Stack:
{quote}
I suggest a design below. It has some prerequisites, some general function
that this feature could use (and others). The prereqs if you think them good,
could be done outside of this JIRA.
Here's a suggested rough outline of how I think this feature should run. The
feature I'm describing below is merge and deleteRegion for I see them as in
essence the same thing.
(C) Client, (M) Master, RS (Region server), ZK (ZooKeeper)
1. Client calls merge or deleteRegion API. API is a range of rows. (C)
2. Master gets call. (M)
3. Master obtains a write lock on table so it can't be disabled from under
us. The write lock will also disable splitting. This is one of the prereqs I
think. Its HBASE-5494 (Or we could just do something simpler where we have a
flag up in zk that splitRegion checks but thats less useful I think; OR we do
the dynamic configs issue and set splits to off via a config. change).
There'd be a timer for how long we wait on the table lock. (M - ZK)
4. If we get the lock, write intent to merge a range up into zk. It also
hoists into zk if its a pure merge or a merge that drops the region data (a
deleteRegion call) (M)
5. Return to the client either our failed attempt at locking the table or an
id of some sort used identifying this running operation; can use it querying
status. (M - C)
6. Turn off balancer. TODO/prereq: Do it in a way that is persisted. Balancer
switch currently in memory only so if master crashes, new master will come up
in balancing mode # (If we had dynamic config. could hoist up to zk a config.
that disables the balancer rather than have a balancer-specific flag/znode OR
if a write lock outstanding on a table, then the balancer does not balance
regions in the locked table - this latter might be the easiest to do) (M)
7. Write into zk that just turned off the balancer (If it was on) (M - ZK)
8. Get regions that are involved in the span (M)
9. Hoist the list up into zk. (M - ZK)
10. Create region to span the range. (M)
11. Write that we did this up into zk. (M - ZK)
12. Close regions in parallel. Confirm close in parallel. (M - RS)
13. Write up into zk regions closed (This might not be necessary since can
ask if region is open). (M - ZK)
14. If a merge and not a delete region, move files under new region. Might
multithread this (moves should go pretty fast). If a deleteregion, we skip
this step. (M)
15. On completion mark zk (though may not be necessary since its easy to look
in fs to see state of move). (M - ZK)
16. Edit .META. (M)
17. Confirm edits went in. (M)
18. Move old regions to hbase trash folder TODO: There is no trash folder
under /hbase currently. We should add one. (M)
19. Enable balancer (if it was off) (M)
20. Unlock table (M)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5504) Online Merge
[
https://issues.apache.org/jira/browse/HBASE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220615#comment-13220615
]
Mubarak Seyed commented on HBASE-5504:
--
bq. Is it possible that there would be more than one master-coordinated task
for the same table running at the same time ?
If we store like /hbase/lock/table_name then we can't. How about
{code}
/hbase/lock/table_name/lockNode1
/lockNode1
{code}
lockNode1 for task1 and be W, lockNode2 for task2 and be R
Online Merge
Key: HBASE-5504
URL: https://issues.apache.org/jira/browse/HBASE-5504
Project: HBase
Issue Type: Brainstorming
Components: client, master, shell, zookeeper
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Fix For: 0.96.0
As discussed, please refer the discussion at
[HBASE-4991|https://issues.apache.org/jira/browse/HBASE-4991]
Design suggestion from Stack:
{quote}
I suggest a design below. It has some prerequisites, some general function
that this feature could use (and others). The prereqs if you think them good,
could be done outside of this JIRA.
Here's a suggested rough outline of how I think this feature should run. The
feature I'm describing below is merge and deleteRegion for I see them as in
essence the same thing.
(C) Client, (M) Master, RS (Region server), ZK (ZooKeeper)
1. Client calls merge or deleteRegion API. API is a range of rows. (C)
2. Master gets call. (M)
3. Master obtains a write lock on table so it can't be disabled from under
us. The write lock will also disable splitting. This is one of the prereqs I
think. Its HBASE-5494 (Or we could just do something simpler where we have a
flag up in zk that splitRegion checks but thats less useful I think; OR we do
the dynamic configs issue and set splits to off via a config. change).
There'd be a timer for how long we wait on the table lock. (M - ZK)
4. If we get the lock, write intent to merge a range up into zk. It also
hoists into zk if its a pure merge or a merge that drops the region data (a
deleteRegion call) (M)
5. Return to the client either our failed attempt at locking the table or an
id of some sort used identifying this running operation; can use it querying
status. (M - C)
6. Turn off balancer. TODO/prereq: Do it in a way that is persisted. Balancer
switch currently in memory only so if master crashes, new master will come up
in balancing mode # (If we had dynamic config. could hoist up to zk a config.
that disables the balancer rather than have a balancer-specific flag/znode OR
if a write lock outstanding on a table, then the balancer does not balance
regions in the locked table - this latter might be the easiest to do) (M)
7. Write into zk that just turned off the balancer (If it was on) (M - ZK)
8. Get regions that are involved in the span (M)
9. Hoist the list up into zk. (M - ZK)
10. Create region to span the range. (M)
11. Write that we did this up into zk. (M - ZK)
12. Close regions in parallel. Confirm close in parallel. (M - RS)
13. Write up into zk regions closed (This might not be necessary since can
ask if region is open). (M - ZK)
14. If a merge and not a delete region, move files under new region. Might
multithread this (moves should go pretty fast). If a deleteregion, we skip
this step. (M)
15. On completion mark zk (though may not be necessary since its easy to look
in fs to see state of move). (M - ZK)
16. Edit .META. (M)
17. Confirm edits went in. (M)
18. Move old regions to hbase trash folder TODO: There is no trash folder
under /hbase currently. We should add one. (M)
19. Enable balancer (if it was off) (M)
20. Unlock table (M)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5504) Online Merge
[
https://issues.apache.org/jira/browse/HBASE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220622#comment-13220622
]
Mubarak Seyed commented on HBASE-5504:
--
[HBASE-5494|https://issues.apache.org/jira/browse/HBASE-5494] says only one
table operation at a time.
@Stack
What happens if task (which held the lock) get stuck?
Online Merge
Key: HBASE-5504
URL: https://issues.apache.org/jira/browse/HBASE-5504
Project: HBase
Issue Type: Brainstorming
Components: client, master, shell, zookeeper
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Fix For: 0.96.0
As discussed, please refer the discussion at
[HBASE-4991|https://issues.apache.org/jira/browse/HBASE-4991]
Design suggestion from Stack:
{quote}
I suggest a design below. It has some prerequisites, some general function
that this feature could use (and others). The prereqs if you think them good,
could be done outside of this JIRA.
Here's a suggested rough outline of how I think this feature should run. The
feature I'm describing below is merge and deleteRegion for I see them as in
essence the same thing.
(C) Client, (M) Master, RS (Region server), ZK (ZooKeeper)
1. Client calls merge or deleteRegion API. API is a range of rows. (C)
2. Master gets call. (M)
3. Master obtains a write lock on table so it can't be disabled from under
us. The write lock will also disable splitting. This is one of the prereqs I
think. Its HBASE-5494 (Or we could just do something simpler where we have a
flag up in zk that splitRegion checks but thats less useful I think; OR we do
the dynamic configs issue and set splits to off via a config. change).
There'd be a timer for how long we wait on the table lock. (M - ZK)
4. If we get the lock, write intent to merge a range up into zk. It also
hoists into zk if its a pure merge or a merge that drops the region data (a
deleteRegion call) (M)
5. Return to the client either our failed attempt at locking the table or an
id of some sort used identifying this running operation; can use it querying
status. (M - C)
6. Turn off balancer. TODO/prereq: Do it in a way that is persisted. Balancer
switch currently in memory only so if master crashes, new master will come up
in balancing mode # (If we had dynamic config. could hoist up to zk a config.
that disables the balancer rather than have a balancer-specific flag/znode OR
if a write lock outstanding on a table, then the balancer does not balance
regions in the locked table - this latter might be the easiest to do) (M)
7. Write into zk that just turned off the balancer (If it was on) (M - ZK)
8. Get regions that are involved in the span (M)
9. Hoist the list up into zk. (M - ZK)
10. Create region to span the range. (M)
11. Write that we did this up into zk. (M - ZK)
12. Close regions in parallel. Confirm close in parallel. (M - RS)
13. Write up into zk regions closed (This might not be necessary since can
ask if region is open). (M - ZK)
14. If a merge and not a delete region, move files under new region. Might
multithread this (moves should go pretty fast). If a deleteregion, we skip
this step. (M)
15. On completion mark zk (though may not be necessary since its easy to look
in fs to see state of move). (M - ZK)
16. Edit .META. (M)
17. Confirm edits went in. (M)
18. Move old regions to hbase trash folder TODO: There is no trash folder
under /hbase currently. We should add one. (M)
19. Enable balancer (if it was off) (M)
20. Unlock table (M)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5504) Online Merge
[
https://issues.apache.org/jira/browse/HBASE-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220661#comment-13220661
]
Mubarak Seyed commented on HBASE-5504:
--
bq. Since region splitting is disabled after step 3, how do we deal with the
case where the start of row range lies in the middle of a region ?
I think we were discussing about start/end key should match with region
boundary (single or multiple), isn't? Are we planning to do arbitrary start/end
key?
Online Merge
Key: HBASE-5504
URL: https://issues.apache.org/jira/browse/HBASE-5504
Project: HBase
Issue Type: Brainstorming
Components: client, master, shell, zookeeper
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Fix For: 0.96.0
As discussed, please refer the discussion at
[HBASE-4991|https://issues.apache.org/jira/browse/HBASE-4991]
Design suggestion from Stack:
{quote}
I suggest a design below. It has some prerequisites, some general function
that this feature could use (and others). The prereqs if you think them good,
could be done outside of this JIRA.
Here's a suggested rough outline of how I think this feature should run. The
feature I'm describing below is merge and deleteRegion for I see them as in
essence the same thing.
(C) Client, (M) Master, RS (Region server), ZK (ZooKeeper)
1. Client calls merge or deleteRegion API. API is a range of rows. (C)
2. Master gets call. (M)
3. Master obtains a write lock on table so it can't be disabled from under
us. The write lock will also disable splitting. This is one of the prereqs I
think. Its HBASE-5494 (Or we could just do something simpler where we have a
flag up in zk that splitRegion checks but thats less useful I think; OR we do
the dynamic configs issue and set splits to off via a config. change).
There'd be a timer for how long we wait on the table lock. (M - ZK)
4. If we get the lock, write intent to merge a range up into zk. It also
hoists into zk if its a pure merge or a merge that drops the region data (a
deleteRegion call) (M)
5. Return to the client either our failed attempt at locking the table or an
id of some sort used identifying this running operation; can use it querying
status. (M - C)
6. Turn off balancer. TODO/prereq: Do it in a way that is persisted. Balancer
switch currently in memory only so if master crashes, new master will come up
in balancing mode # (If we had dynamic config. could hoist up to zk a config.
that disables the balancer rather than have a balancer-specific flag/znode OR
if a write lock outstanding on a table, then the balancer does not balance
regions in the locked table - this latter might be the easiest to do) (M)
7. Write into zk that just turned off the balancer (If it was on) (M - ZK)
8. Get regions that are involved in the span (M)
9. Hoist the list up into zk. (M - ZK)
10. Create region to span the range. (M)
11. Write that we did this up into zk. (M - ZK)
12. Close regions in parallel. Confirm close in parallel. (M - RS)
13. Write up into zk regions closed (This might not be necessary since can
ask if region is open). (M - ZK)
14. If a merge and not a delete region, move files under new region. Might
multithread this (moves should go pretty fast). If a deleteregion, we skip
this step. (M)
15. On completion mark zk (though may not be necessary since its easy to look
in fs to see state of move). (M - ZK)
16. Edit .META. (M)
17. Confirm edits went in. (M)
18. Move old regions to hbase trash folder TODO: There is no trash folder
under /hbase currently. We should add one. (M)
19. Enable balancer (if it was off) (M)
20. Unlock table (M)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219436#comment-13219436
]
Mubarak Seyed commented on HBASE-4991:
--
We are going to remove
{code}
public int getRegionsCount(byte[] regionName) throws IOException
{code}
as we will use getOnlineRegions() and process them in client-side, please refer
my comment @ 24/Feb/12 00:16
Will read the onlineMerge code.
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219477#comment-13219477
]
Mubarak Seyed commented on HBASE-4991:
--
@Stack
bq.This feature looks to be adding online merge to me. I need clarification
from Mubarak that that is indeed the case. If so, this issue is mislabeled and
the patch needs redoing.
Online merge requires table needs to be disabled but deleteRegion (deleteRange)
does not require table needs to be disabled.
We were discussing about making use of HMerge.merge() (please refer my comment
@ 27/Jan/12 06:36) but it checks for half of region-size
{code}
this.maxFilesize = conf.getLong(HConstants.HREGION_MAX_FILESIZE,
HConstants.DEFAULT_MAX_FILE_SIZE);
..
if ((currentSize + nextSize) = (maxFilesize / 2)) {
// We merge two adjacent regions if their total size is less than
// one half of the desired maximum size
{code}
so, in this case an adjacent region size can be half of max of region-size?
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219575#comment-13219575 ] Mubarak Seyed commented on HBASE-4991: -- bq.So, we are agreed that conceptually, whats going on here is region merging? Merge with two-regions-data Vs Merge-with-one-region-data We do merge just to cover META hole, isn't? IMO deleteRange is a task/function from cmdLine/API and we do use merge for an implementation (as part of the task) Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219649#comment-13219649 ] Mubarak Seyed commented on HBASE-4991: -- @Stack bq. sounds like the command/api could also be named merge rather than deleteRegion (You are not actually deleting the data, is that right?)? We do delete the data of region (to be deleted) The real confusion with the terminology here is that merge makes 2 or more regions into one with data remains same (but the start/end keys are different after the merge) but deleteRegion makes one region (or multiple regions) data will be deleted from HDFS (and make a single region in meta with modified start/end key). For example: We have three regions namely R1, R2, and R3 When we do merge R2 with R3 - new region would be (R2R3)' and data of R2 and R3 will be moved to (R2R3)' so, in META it would look like R1 - start/end key, location (R2R3)' - modified start/end key, location r4 - start/end key, location When we do deleteRange of single region (R2) - new region would be (R1)', meaning R1 end key be R2s end key, data of R2 will be deleted, and R1 data will be merged with R1' so, in META it would look like (R1)' - modified start/end key, location R3 - start/end key, location Make sense? Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219685#comment-13219685
]
Mubarak Seyed commented on HBASE-4991:
--
bq. Implementation-wise, this is a merge with the added option that we not copy
the data of the regions we are merging.
Agreed but if we name the command like
{code}
merge table_name start_key end_key
{code}
then it means that clubbing multiple (2 or more) to a single region (provided
data remains same)
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219706#comment-13219706
]
Mubarak Seyed commented on HBASE-4991:
--
bq. What do we have the regionserver do anything but close of the region? Why
do we delegate to it the deletion? Why not have it done by the master? Or a
client script? Have it remove the region from .META. and from the fs? And
bridge the hole in .META.? Isn't that less complicated?
Well, client's deleteRegion call is asynchronous so no fail-over if client has
to do the business.
Regarding master, it acts as a coordinator between client and RS, meaning it is
like move() region task (but split() goes from client to RS). Master does the
cleanup job of deleting the failed delete-region znodes if they exceeds the
configured timeout value (30 minutes)
{code}
this.deleteRegionTracker = new MasterDeleteRegionTracker(getZooKeeper(),
this,this, conf.getInt(hbase.delete.region.timeout, 180));
{code}
If we have to make client call to RS (as like compact or split) for
deleteRegion then how do we do clean-up? How about master-failover?
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219840#comment-13219840 ] Mubarak Seyed commented on HBASE-4991: -- bq. I was suggesting doing it as a client script because then it'd be outside of the servers and easier to test. If client dies, restart it, it looks in zk for work to do and carries on from where the last client was. But no biggie. Is it something like jruby script (like region_mover.rb) in HBASE_HOME/bin dir? What happens if balancer is running or split is in middle for that region? I guess the script should check to see if there is a zookeeper.znode.parent/unassigned/region-to-be-deleted and RS should ignore split request if the region is in middle of deletion (by looking at zookeeper.znode.parent/delete-region/region-to-be-deleted) bq. What about my question about why we delegate merge/delete out to the regionservers? Why not have them do nothing but the close and then have the master do the remove or merging of fs content and fixup in meta? Would that be less moving parts? Master delegate tasks to RS (eg: openRegion for assignment, closeRegion for move), are you asking something like a handler in master side to do the remove or merging of fs content and fixup in meta? We can as long as required methods are public in HRegionInterface (How about HRegion as we can't serialize it?) Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219856#comment-13219856 ] Mubarak Seyed commented on HBASE-4991: -- Thanks Stack for your suggestions. Will think a bit. bq. How many regions are we talking of merging/deleting at any one time? I think above should work for a big table as long was we did stuff in parallel; closes and file moving. To be confirmed. I have tested for one region at a time but if i change the code for multiple regions then it will work in parallel as each RS will do process as long as regions-to-be-deleted are part of online regions list. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219876#comment-13219876 ] Mubarak Seyed commented on HBASE-4991: -- @Stack In your proposal, 2 to 4 are synchronous (client gets blocked) in master side, 5 returns the task id (Or error) to client, 6 to 9 are again in master side, 10 to 18 goes to RS side, and 19 to 20 in master side We need ZK trackers in both sides, isn't? Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219882#comment-13219882 ] Mubarak Seyed commented on HBASE-4991: -- bq. Does the above presume all regions for a range are on a single regionserver (If not, how is the meta editing done – in particular the bridging of the hole in .META.?). No, the design was intended for a single region Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217654#comment-13217654 ] Mubarak Seyed commented on HBASE-4991: -- @Stack, Is there any update on this issue? Do i need to halt the progress of this issue until design is ironed out? Please let me know. Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215482#comment-13215482
]
Mubarak Seyed commented on HBASE-4991:
--
bq. How does Accumulo do it do you know? You might get some ideas over there.
Will take a look. Todd's preso highlights comparison of HBase vs Accumulo -
http://www.slideshare.net/cloudera/h-base-and-accumulo-todd-lipcom-jan-25-2012
Source:
https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src/server/src/main/java/org/apache/accumulo/server/fate/
(Master-coordinated tasks uses Fate, refer TStore.java)
https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src/server/src/main/java/org/apache/accumulo/server/master/Master.java
Notes from TStore.java
{code}
/**
* Transaction Store: a place to save transactions
*
* A transaction consists of a number of operations. To use, first create a
transaction id, and then seed the
* transaction with an initial operation. An executor service can then execute
the transaction's operation,
* possibly pushing more operations onto the transaction as each step
successfully completes.
* If a step fails, the stack can be unwound, undoing each operation.
*/
{code}
For example, delete-range operation in master uses fate to seed transaction
with an DELETE_RANGE table operation, submit a task, executor service can then
execute the op.
{code}
public void executeTableOperation(TInfo tinfo, AuthInfo c, long opid,
org.apache.accumulo.core.master.thrift.TableOperation op, ListByteBuffer
arguments, MapString,String options, boolean autoCleanup){
case DELETE_RANGE: {
String tableName = ByteBufferUtil.toString(arguments.get(0));
Text startRow = ByteBufferUtil.toText(arguments.get(1));
Text endRow = ByteBufferUtil.toText(arguments.get(2));
final String tableId = checkTableId(tableName,
TableOperation.DELETE_RANGE);
checkNotMetadataTable(tableName, TableOperation.DELETE_RANGE);
verify(c, tableId, TableOperation.DELETE_RANGE, check(c,
SystemPermission.SYSTEM) || check(c, tableId, TablePermission.WRITE));
fate.seedTransaction(opid, new TraceRepoMaster(new
TableRangeOp(MergeInfo.Operation.DELETE, tableId, startRow, endRow)),
autoCleanup);
break;
}
}
{code}
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5183) Render the monitored tasks as a treeview
[
https://issues.apache.org/jira/browse/HBASE-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215991#comment-13215991
]
Mubarak Seyed commented on HBASE-5183:
--
I believe we need to present the monitored task as TreeView + Table (treeTable).
The first column is a tree with root/node/leaf, 2nd to 5th shows startTime,
description, state and status.
Something like http://ludo.cubicphuse.nl/jquery-plugins/treeTable/doc/
How do we group data?
Option 1: Group-by StartTime
{code}
Start time | Description |
State| Status
+ Mon Feb 20 15:10:08 PST 2012 IPC Server handler 99 on 6
WAITING (since 4mins, 8sec ago) Waiting for a call (since ..)
IPC Server handler 20 on 6
WAITING (since 2mins, 1sec ago) Waiting for a call (since ..)
+ Mon Feb 22 17:18:18 PST 2012 IPC Server handler 40 on 6
WAITING (since 0mins, 30sec ago) Waiting for a call (since ..)
{code}
Option 2: Group-by State
Option 3: Group-by Status
I believe StartTime is almost same for all the IPC server handler as Master or
RS pages shows the same startTime (depends on when we restart daemons).
Option 2 and 3 are more of a text based grouping.
Thoughts?
Render the monitored tasks as a treeview
Key: HBASE-5183
URL: https://issues.apache.org/jira/browse/HBASE-5183
Project: HBase
Issue Type: Sub-task
Reporter: Zhihong Yu
Assignee: Mubarak Seyed
Fix For: 0.92.2, 0.94.0
Andy made the suggestion here:
https://issues.apache.org/jira/browse/HBASE-5174?focusedCommentId=13184571page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13184571
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216122#comment-13216122 ] Mubarak Seyed commented on HBASE-4991: -- bq.I don't see how plan of ' 01/Feb/12 07:43' lays foundation for a generic framework. Am I missing something? It seems like its code for this feature only? My initial skeleton was only limited to 4991 implementation, framework idea was not part of intent of 4991. Todd's comment in code review @ '16/Feb/2012 7:42' (https://reviews.apache.org/r/3917/) brought the idea of Accumulo's FATE and it turns out as generic framework. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214945#comment-13214945
]
Mubarak Seyed commented on HBASE-5434:
--
@Stack
When i tested with -P runMediumTests, it went well but code annotate as
smallTests, will update a patch soon. Sorry for the inconvenience. Thanks.
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215243#comment-13215243
]
Mubarak Seyed commented on HBASE-4991:
--
bq. could use: 'ListHRegionInfo getOnlineRegions() ' HRIs have
tablename. Could figure it client-side
Make sense, will do it in client-side, i have tried with getting a
ListHRegion, got into serialization issue
bq. Will we have a new dir in zk per cluster region operation we want to do?
Can we not exploit primitives added by hbase-4213? Or do we need to refactor
hbase-4213 to get you primitives you need to do this facility? Or is there
nothing in common w/ what hbase-4213 does (there is at least the closing of a
region?)
We can certainly refactor HBASE-4213 MasterSchemaChangeTracker and
SchemaChangeTracker, we can club them as single tracker on each side (Master
and RS), will dig more.
bq. online merge should have a bunch of overlap w/ this feature? Would be great
if they could share a bunch of code/primitives.
Sure, more refactoring
bq. As has been suggested, rather than a /delete-region, instead we'd have a
log of intent+log of actions thing up in zk I suppose. The log of intent would
list the steps to be done and then the log of actions thingy would log how far
the operation had gone
We are using znode just to start the task and update the state only. If we keep
track of intent vs action in same znode, considering the size of data in znode,
we should not exceed 1 MB as ZK admin guide says
{panel:title=jute.maxbuffer| borderStyle=dashed| borderColor=#ccc|
titleBGColor=#F7D6C1| bgColor=#CE}
(Java system property: jute.maxbuffer)
This option can only be set as a Java system property. There is no zookeeper
prefix on it. It specifies the maximum size of the data that can be stored in a
znode. The default is 0xf, or just under 1M. If this option is changed, the
system property must be set on all servers and clients otherwise problems will
arise. This is really a sanity check. ZooKeeper is designed to store data on
the order of kilobytes in size.
{panel}
Can we address it in another JIRA as we need to persist znode with MapIntent,
Action?
bq.Thats a bit broken in my opinion. Its wonky having zk have reference out to
other main packages. Not your fault. Should have caught that in review of
hbase-4213.
Well, we can still refactor (club schema change trackers and delete-region
trackers into one) and place them into appropriate package?
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215288#comment-13215288
]
Mubarak Seyed commented on HBASE-4991:
--
@Stack,
{quote}
The log of intent would list the steps to be done
Is it Okay to do the above in another JIRA ?
As a prereq for this issue? Yes.
{quote}
Please correct me if i am wrong, if we introduce prereq then we need to design
(as you asked) the intent part (a bare mini language..) and actual
delete_region implementation needs to interpret (as Ted mentioned) the steps
from intent (from ZK). Do we need to design the intent part (and steps of an
operation) as a generic framework for all the master-coordinated tasks?
I thought we are only changing the API (with multiple region support) and
focussing more on refactoring with good test/stress-test in this JIRA.
Can we address intent/actions part out of scope of this JIRA?
Thoughts?
Thanks.
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5433) [REST] Add metrics to keep track of success/failure count
[
https://issues.apache.org/jira/browse/HBASE-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213869#comment-13213869
]
Mubarak Seyed commented on HBASE-5433:
--
bq. can you see the metrics coming out in your metrics system? They show ok?
Tested in live cluster, could see metrics in Ganglia. Thanks.
[REST] Add metrics to keep track of success/failure count
-
Key: HBASE-5433
URL: https://issues.apache.org/jira/browse/HBASE-5433
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5433.trunk.v1.patch
In a production environment, the visibility of successful REST request(s) are
not getting exposed to metric system as we have only one metric (requests)
today.
Proposing to add more metrics such as successful_get_count, failed_get_count,
successful_put_count, failed_put_count
The current implementation increases the request count at the beginning of
the method implementation and it is very hard to monitor requests (unless
turn on debug, find the row_key and validate it in get/scan using hbase
shell), it will be very useful to ops to keep an eye as requests from cross
data-centers are trying to write data to one cluster using REST gateway
through load balancer (and there is no visibility of which REST-server/RS
failed to write data)
{code}
Response update(final CellSetModel model, final boolean replace) {
// for requests
servlet.getMetrics().incrementRequests(1);
..
..
table.put(puts);
table.flushCommits();
ResponseBuilder response = Response.ok();
// for successful_get_count
servlet.getMetrics().incrementSuccessfulGetRequests(1);
return response.build();
} catch (IOException e) {
// for failed_get_count
servlet.getMetrics().incrementFailedGetRequests(1);
throw new WebApplicationException(e,
Response.Status.SERVICE_UNAVAILABLE);
} finally {
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213878#comment-13213878
]
Mubarak Seyed commented on HBASE-5434:
--
Could not get _compactionProgressPct_ value as it depends on
[HBASE-3943|https://issues.apache.org/jira/browse/HBASE-3943], so
_compactionProgressPct_ will not be included in output. Thanks.
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213897#comment-13213897
]
Mubarak Seyed commented on HBASE-5434:
--
Need to update schema definition in wiki page
http://wiki.apache.org/hadoop/Hbase/Stargate
*protobufs schema*
{code}
message StorageClusterStatus {
message Region {
required bytes name = 1;
optional int32 stores = 2;
optional int32 storefiles = 3;
optional int32 storefileSizeMB = 4;
optional int32 memstoreSizeMB = 5;
optional int32 storefileIndexSizeMB = 6;
optional int64 readRequestsCount = 7;
optional int64 writeRequestsCount = 8;
optional int32 rootIndexSizeKB = 9;
optional int32 totalStaticIndexSizeKB = 10;
optional int32 totalStaticBloomSizeKB = 11;
optional int64 totalCompactingKVs = 12;
optional int64 currentCompactedKVs = 13;
{color}
}
..
}
{code}
*XML schema*
{code}
complexType name=Region
attribute name=name type=base64Binary/attribute
attribute name=stores type=int/attribute
attribute name=storefiles type=int/attribute
attribute name=storefileSizeMB type=int/attribute
attribute name=memstoreSizeMB type=int/attribute
attribute name=storefileIndexSizeMB type=int/attribute
attribute name=readRequestsCount type=int/attribute
attribute name=writeRequestsCount type=int/attribute
attribute name=rootIndexSizeKB type=int/attribute
attribute name=totalStaticIndexSizeKB type=int/attribute
attribute name=totalStaticBloomSizeKB type=int/attribute
attribute name=totalCompactingKVs type=int/attribute
attribute name=currentCompactedKVs type=int/attribute
/complexType
{code}
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213905#comment-13213905
]
Mubarak Seyed commented on HBASE-5434:
--
@Andrew
Can you please review the patch? Thanks.
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214051#comment-13214051
]
Mubarak Seyed commented on HBASE-5434:
--
Thanks Andrew.
@Ted.
Can you please take care of updating the wiki page once it is committed as i
don't have an access? Thanks.
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214071#comment-13214071
]
Mubarak Seyed commented on HBASE-4991:
--
@Stack
Thanks for the review
bq.Do we need to add this method to the region server interface?
bq.{code}
+ public int getRegionsCount(byte[] regionName) throws IOException;
{code}
bq.Can we not just count what comes back from the get on online regions?
We need to get the counts per table, _getOnlineRegions_ returns _ListHRegion_
for a table but client does not know the _tableName_ for a _regionName_ in our
case, either we can do two calls (one for getting _HRegionInfo_ and get
_tableName_ from there and next one for getting _ListHRegion_). I thought we
can simplify by adding a new interface.
{code}
public int getRegionsCount(byte[] regionName) throws IOException {
return getOnlineRegions(getRegionInfo(regionName).getTableName())
.size();
}
{code}
bq. Do we have to run the region delete in the Master process? Can the client
not do it?
Design choice is like
[HBASE-4213|https://issues.apache.org/jira/browse/HBASE-4213], meaning master
create a znode under _zookeeper.znode.parent/delete-region_ then RS trackers
are getting notified of children changed, then a RS which hosts the region
to-be-deleted will process the delete-region request and update the state in
_zookeeper.znode.parent/delete-region/encoded-region-name-to-be-deleted_
znode.
bq.Is it really necessary adding + public MasterDeleteRegionTracker
getDeleteRegionTracker(); to the MasterServices? This will have a ripple effect
through Tests and it seems like a bit of an exotic API to have in this basic
Interface.
Will think a bit more and update you
bq.Does all of this new code need to be in HRegionServer? Can it live in a
class of its own?
Like to hear the comments from code review, we can refactor to helper class.
bq. There must be a million holes here (HRS crashes in middle of file moving or
creation of the merged region, files partially moved or deleted).
I believe _delete-region_ state in ZK will help to recover from failures, need
more testcases with individual failure scenarios such as HRS crash, failure of
merged region, failure of file remove in HDFS, failure of new region directory
creation in HDFS, partial files, etc, will add them when i do stress test for
Todd's suggestion
bq. Does this code all need to be in core? Can we not make a few primitives and
then run it all from outside in a tool or script w/ state recorded as we go so
can resume if fail mid-way? There are a bunch of moving pieces here. Its all
bundled up in core code so its going to be tough to test.
If we are considering _delete_region_ as a tool/util then we can refactor as a
tool/util as like Online/Offline merge code.
bq.Adding this to onlineregions, + public void deleteRegion(String regionName)
throws IOException, KeeperException;, do all removals from online regions now
use this new API (Its probably good having it here... but just wondering about
the places where regions currently get removed from online map, do they go a
different route than this new one?)
New API _deleteRegion()_ does more than just removing from online region(s) map
but other places we use
{code}
public boolean removeFromOnlineRegions(final String encodedName)
{code}
Its being called from _openRegion()_, _refreshRegion()_, _createDaughters()_ in
_SplitTransaction_ and _CloseRegionHandler_
bq. How hard will it be to reuse parts to do say an online merge of a bunch of
adjacent regions?
Once Todd's proposal is implemented, will find out a way to do more refactoring
(to cut down repeated code)
bq. Are the enums duplicated?
Yes, will take care of it in refactoring.
bq. Why does zookeeper package have classes particular to master and
regionserver?
We do put all our ZK trackers in zookeeper package and this is how online
schema change [HBASE-4213|https://issues.apache.org/jira/browse/HBASE-4213] was
implemented.
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5434) [REST] Include more metrics in cluster status request
[
https://issues.apache.org/jira/browse/HBASE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214116#comment-13214116
]
Mubarak Seyed commented on HBASE-5434:
--
@Stack
My wiki id is Mubarak Seyed. Thanks
[REST] Include more metrics in cluster status request
-
Key: HBASE-5434
URL: https://issues.apache.org/jira/browse/HBASE-5434
Project: HBase
Issue Type: Improvement
Components: metrics, rest
Affects Versions: 0.94.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
Fix For: 0.94.0
Attachments: HBASE-5434.trunk.v1.patch
/status/cluster shows only
{code}
stores=2
storefiless=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
{code}
for a region but master web-ui shows
{code}
stores=1,
storefiles=0,
storefileUncompressedSizeMB=0
storefileSizeMB=0
memstoreSizeMB=0
storefileIndexSizeMB=0
readRequestsCount=0
writeRequestsCount=0
rootIndexSizeKB=0
totalStaticIndexSizeKB=0
totalStaticBloomSizeKB=0
totalCompactingKVs=0
currentCompactedKVs=0
compactionProgressPct=NaN
{code}
In a write-heavy REST gateway based production environment, ops team needs to
verify whether write counters are getting incremented per region (they do run
/status/cluster on each REST server), we can get the same values from
*rpc.metrics.put_num_ops* and *hbase.regionserver.writeRequestsCount* but
some home-grown tools needs to parse the output of /status/cluster and
updates the dashboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5459) Provide capability to find the status of Master coordinated tasks
[ https://issues.apache.org/jira/browse/HBASE-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214130#comment-13214130 ] Mubarak Seyed commented on HBASE-5459: -- Master/RS WebUI shows monitored tasks for master-coordinated tasks. In a production environment with 100s of RS, it will be handy to run a command from shell and get the status as we do track the state in ZK for each task. Thanks. Provide capability to find the status of Master coordinated tasks - Key: HBASE-5459 URL: https://issues.apache.org/jira/browse/HBASE-5459 Project: HBase Issue Type: Improvement Components: client, shell Affects Versions: 0.94.0 Reporter: Mubarak Seyed Labels: noob In HBASE-4991 review comments (https://reviews.apache.org/r/3917/), Todd was commenting about Accumulo's [FATE framework|https://svn.apache.org/repos/asf/incubator/accumulo/site/trunk/content/accumulo/notable_features.mdtext]. It will be good to have a command in shell to find the status of online schema change, delete_region (HBASE-4991) and other master-coordinated tasks. Reference: [ACCUMULO-317|https://issues.apache.org/jira/browse/ACCUMULO-317] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214224#comment-13214224 ] Mubarak Seyed commented on HBASE-4991: -- How about _deleteRegion(tableName, startKey, endKey)_? Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214223#comment-13214223 ] Mubarak Seyed commented on HBASE-4991: -- If we specify only start and end key, what happens if multiple regions (belongs to mutiple tables) holds the same start/end key? For example: I have 3 tables = table1, table2, table3 If i pre-split them using first two characters like [0-9][a-z]= we get 36 x 36 = 1296 regions = 1296 x 3 = 3888 total regions (across all RSs), so key would look like a0 to az. .. z0... to zz... .. 01... to 0z... so we end up table1,region1,start_key1,end_key1 table2,region1,start_key1,end_key1 table3,region1,start_key1,end_key1 start_key1 and end_key1 needs to be resolved at input level unless fully qualified path of _table1,region1,start_key1_ and _table1,region1,end_key1_ is specified. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214239#comment-13214239 ] Mubarak Seyed commented on HBASE-4991: -- From the above discussions, this is what i am thinking to implement - Shell command needs to be changed as _delete_region table_name start_key end_key_ - API will be changed to _deleteRegion(tableName, startKey, endKey)_ in HBaseAdmin - If there is no match for start/end key for the specified table then just error out - If start/end key for the specified table is spanned across multiple regions then it is out of scope of this JIRA (throw error). Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214337#comment-13214337 ] Mubarak Seyed commented on HBASE-4991: -- bq. So, you can only do one region at a time? Why would it be hard doing multiple given you are tracking? Or is it that it makes the tracking yet more complicated? As long as start/end keys are in region(s) boundary, we can do multiple regions, each region's encoded name will be added under _zookeeper.znode.parent/delete-region_ as one znode. For example, we have regions R1, R2, R3 and R4, what i meant was if startKey is startKey of R1, spans across R2, R3 and endKey is some value other than endKey of R4 then we will error out an entire task. I believe 4th point in my previous comment at 23/Feb/12 02:43 needs to be removed as 3rd point covers well. Sorry for the confusion. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212231#comment-13212231 ] Mubarak Seyed commented on HBASE-4991: -- Thanks Todd. Will come up with testcases and run the stress test. Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211169#comment-13211169 ] Mubarak Seyed commented on HBASE-4991: -- @Todd, @Nicolas Can i go ahead with changes or we need more time for brainstorming? Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4991.trunk.v1.patch, HBASE-4991.trunk.v2.patch See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5189) Add metrics to keep track of region-splits in RS
[ https://issues.apache.org/jira/browse/HBASE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211176#comment-13211176 ] Mubarak Seyed commented on HBASE-5189: -- Tested in live cluster, works fine. Thanks. Add metrics to keep track of region-splits in RS Key: HBASE-5189 URL: https://issues.apache.org/jira/browse/HBASE-5189 Project: HBase Issue Type: Improvement Components: metrics, regionserver Affects Versions: 0.90.5, 0.92.0 Reporter: Mubarak Seyed Assignee: Mubarak Seyed Priority: Minor Labels: noob Fix For: 0.94.0 Attachments: HBASE-5189.trunk.v1.patch, HBASE-5189.trunk.v2.patch For write-heavy workload with region-size 1 GB, region-split is considerably high. We do normally grep the NN log (grep mkdir*.split NN.log | sort | uniq -c) to get the count. I would like to have a counter incremented each time region-split execution succeeds and this counter exposed via the metrics stuff in HBase. - regionSplitSuccessCount - regionSplitFailureCount (will help us to correlate the timestamp range in RS logs across all RS) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5183) Render the monitored tasks as a treeview
[ https://issues.apache.org/jira/browse/HBASE-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211207#comment-13211207 ] Mubarak Seyed commented on HBASE-5183: -- Working on it, will attach screenshots for discussion. Thanks. Render the monitored tasks as a treeview Key: HBASE-5183 URL: https://issues.apache.org/jira/browse/HBASE-5183 Project: HBase Issue Type: Sub-task Reporter: Zhihong Yu Assignee: Mubarak Seyed Fix For: 0.94.0, 0.92.2 Andy made the suggestion here: https://issues.apache.org/jira/browse/HBASE-5174?focusedCommentId=13184571page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13184571 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210671#comment-13210671 ] Mubarak Seyed commented on HBASE-3149: -- @Nicolas, Is there any update on this issue? We have a production use-case wherein 80% of data goes to one CF and remaining 20% goes to two other CFs. I can collaborate with you if you are interested to pursue with patch. Thanks. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Today, the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210698#comment-13210698 ] Mubarak Seyed commented on HBASE-3149: -- Thanks Nicolas. Will try with 4 MB and create a JIRA. Make flush decisions per column family -- Key: HBASE-3149 URL: https://issues.apache.org/jira/browse/HBASE-3149 Project: HBase Issue Type: Improvement Components: regionserver Reporter: Karthik Ranganathan Assignee: Nicolas Spiegelberg Today, the flush decision is made using the aggregate size of all column families. When large and small column families co-exist, this causes many small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204740#comment-13204740 ] Mubarak Seyed commented on HBASE-5349: -- For reference: Cassandra 1.0.0 supports self-tunes memtable sizes ([CASSANDRA-2787|https://issues.apache.org/jira/browse/CASSANDRA-2787]). It uses Java agent ([Jamm|https://github.com/jbellis/jamm]) Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204998#comment-13204998 ] Mubarak Seyed commented on HBASE-4720: -- The following scenarios are tested: 1. 5 nodes dev cluster, running trunk * Generated load with curl for checkAndPut/checkAndDelete, tested for functional verification * Developed a test client, which uses HBaseAdmin APIs to test the atomic operations functionality (for positive/negative testcases) 2. 7 nodes perf cluster, running trunk * Developed a test client, which uses HBaseAdmin APIs to test the atomic operations functionality (for positive/negative testcases). Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202736#comment-13202736 ] Mubarak Seyed commented on HBASE-4991: -- Waiting for corporate approval to contribute this patch. Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu Assignee: Mubarak Seyed Fix For: 0.94.0 See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4528) The put operation can release the rowlock before sync-ing the Hlog
[ https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199301#comment-13199301 ] Mubarak Seyed commented on HBASE-4528: -- Is there any plan on backporting to 92.1 and/or 0.90.7? The put operation can release the rowlock before sync-ing the Hlog -- Key: HBASE-4528 URL: https://issues.apache.org/jira/browse/HBASE-4528 Project: HBase Issue Type: Improvement Components: regionserver Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0 Attachments: 4528-trunk-v9.txt, 4528-trunk.txt, HBASE-4528-Trunk-FINAL.patch, appendNoSync5.txt, appendNoSyncPut1.txt, appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt, appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt, appendNoSyncPut8.txt This allows for better throughput when there are hot rows. A single row update improves from 100 puts/sec/server to 5000 puts/sec/server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3850) Log more details when a scanner lease expires
[
https://issues.apache.org/jira/browse/HBASE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197401#comment-13197401
]
Mubarak Seyed commented on HBASE-3850:
--
RegionScanner.getRegionInfo().getTableNameAsString() will give table name.
Log more details when a scanner lease expires
-
Key: HBASE-3850
URL: https://issues.apache.org/jira/browse/HBASE-3850
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: Benoit Sigoure
Assignee: Darren Haas
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-3850.trunk.v1.patch
The message logged by the RegionServer when a Scanner lease expires isn't as
useful as it could be. {{Scanner 4765412385779771089 lease expired}} - most
clients don't log their scanner ID, so it's really hard to figure out what
was going on. I think it would be useful to at least log the name of the
region on which the Scanner was open, and it would be great to have the
ip:port of the client that had that lease too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3859) Increment a counter when a Scanner lease expires
[ https://issues.apache.org/jira/browse/HBASE-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197436#comment-13197436 ] Mubarak Seyed commented on HBASE-3859: -- @Stack Unit test-suite passed. Working on to test it out in cluster to see the metric in Ganglia. Thanks. Increment a counter when a Scanner lease expires Key: HBASE-3859 URL: https://issues.apache.org/jira/browse/HBASE-3859 Project: HBase Issue Type: Improvement Components: metrics, regionserver Affects Versions: 0.90.2 Reporter: Benoit Sigoure Assignee: Mubarak Seyed Priority: Minor Attachments: HBASE-3859.trunk.v1.patch Whenever a Scanner lease expires, the RegionServer will close it automatically and log a message to complain. I would like the RegionServer to increment a counter whenever this happens and expose this counter through the metrics system, so we can plug this into our monitoring system (OpenTSDB) and keep track of how frequently this happens. It's not supposed to happen frequently so it's good to keep an eye on it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197647#comment-13197647 ] Mubarak Seyed commented on HBASE-4991: -- 1. HBaseAdmin needs to have deleteRegion(byte[] encodedRegionName), which invokes getMaster().deleteRegion(encodedRegionName) (HMasterInterface will have deleteRegion(byte[] encodedRegionName)) 2. HMaster needs to have deleteRegion(byte[] encodedRegionName). * Do we need pre/post CP here? * Need DeleteRegionHandler, need to check whether specified region belongs to user regions (shouldn't be ROOT or META), turn off load balancer. 3. MasterDeleteRegionTracker (new class) will create deleteRegionNode (under zookeeper.znode.parent/delete-region) and processing steps are almost like MasterSchemaChangeTracker 4. DeleteRegionTracker (new class in RS side) will process nodeChildrenChanged(), get the list of regions_to_be_deleted, check that those regions are being hosted by the RS, if yes then * doDeleteRegion ** call deleteRegion() in HRegionServer *** disable the region split *** close the region *** remove from META *** bridge the whole in META (extending the span of before or after region) *** remove region directory from HDFS ** update state in ZK (zookeeper.znode.parent/delete-region/encoded-region-name) 5. MasterDeleteRegionTracker gets nodeDataChanged() Zk event, process the new state and clean the znode (if region is deleted successfully) otherwise log the debug message I think i am missing some of the failure cases: * update of before or after region * Master fail-over Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5256) Use WritableUtils.readVInt() in RegionLoad.readFields()
[ https://issues.apache.org/jira/browse/HBASE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195646#comment-13195646 ] Mubarak Seyed commented on HBASE-5256: -- Waiting for corporate approval to contribute this patch. Thanks. Use WritableUtils.readVInt() in RegionLoad.readFields() --- Key: HBASE-5256 URL: https://issues.apache.org/jira/browse/HBASE-5256 Project: HBase Issue Type: Task Reporter: Zhihong Yu Assignee: Mubarak Seyed Fix For: 0.94.0 Currently in.readInt() is used in RegionLoad.readFields() More metrics would be added to RegionLoad in the future, we should utilize WritableUtils.readVInt() to reduce the amount of data exchanged between Master and region servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195038#comment-13195038
]
Mubarak Seyed commented on HBASE-4720:
--
@Ted
I have tested with unit test suite (using -P runMediumTests)
{code}
Running org.apache.hadoop.hbase.rest.TestMultiRowResource
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.421 sec
2012-01-27 11:32:49.762 java[82087:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestGzipFilter
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.149 sec
2012-01-27 11:32:58.404 java[82108:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestRowResource
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.876 sec
2012-01-27 11:33:27.716 java[82119:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestScannerResource
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 43.012 sec
2012-01-27 11:33:42.335 java[82141:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestScannersWithFilters
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.465 sec
2012-01-27 11:33:55.059 java[82151:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestStatusResource
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.569 sec
2012-01-27 11:34:16.689 java[82160:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestSchemaResource
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 54.973 sec
2012-01-27 11:34:38.275 java[82181:10803] Unable to load realm info from
SCDynamicStore
Running org.apache.hadoop.hbase.rest.TestTableResource
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 40.286 sec
Running org.apache.hadoop.hbase.rest.TestVersionResource
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.001 sec
Results :
Tests run: 51, Failures: 0, Errors: 0, Skipped: 0
{code}
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch,
HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch,
HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch,
HBASE-4720.trunk.v7.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[ https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194103#comment-13194103 ] Mubarak Seyed commented on HBASE-4991: -- Do we need add a command under tools in hbase shell (with public API for delete named region)? How about this? hbase(main) delete_region region_name compact and major_compact supports region-name as an argument, can we use the same approach? Thanks. Provide capability to delete named region - Key: HBASE-4991 URL: https://issues.apache.org/jira/browse/HBASE-4991 Project: HBase Issue Type: Improvement Reporter: Ted Yu See discussion titled 'Able to control routing to Solr shards or not' on lily-discuss User may want to quickly dispose of out of date records by deleting specific regions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4991) Provide capability to delete named region
[
https://issues.apache.org/jira/browse/HBASE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194517#comment-13194517
]
Mubarak Seyed commented on HBASE-4991:
--
I think we can make use of
{code}
protected boolean merge(final HRegionInfo[] info) throws IOException {
if ((currentSize + nextSize) = (maxFilesize / 2)) {
// We merge two adjacent regions if their total size is less than
// one half of the desired maximum size
LOG.info(Merging regions + currentRegion.getRegionNameAsString() +
and + nextRegion.getRegionNameAsString());
HRegion mergedRegion =
HRegion.mergeAdjacent(currentRegion, nextRegion);
updateMeta(currentRegion.getRegionName(), nextRegion.getRegionName(),
mergedRegion);
break;
}
}
{code}
what happens if sum(previous_region_size and next_region_size ) maxFileSize
when we try to merge adjacent regions (to bridge the hole)?
Provide capability to delete named region
-
Key: HBASE-4991
URL: https://issues.apache.org/jira/browse/HBASE-4991
Project: HBase
Issue Type: Improvement
Reporter: Ted Yu
See discussion titled 'Able to control routing to Solr shards or not' on
lily-discuss
User may want to quickly dispose of out of date records by deleting specific
regions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4917) CRUD Verify Utility
[
https://issues.apache.org/jira/browse/HBASE-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193259#comment-13193259
]
Mubarak Seyed commented on HBASE-4917:
--
@Nicolas,
How different this LoadTest tool from PerformanceEvaluation
{code}
hbase org.apache.hadoop.hbase.PerformanceEvaluation
Usage: java org.apache.hadoop.hbase.PerformanceEvaluation \
[--miniCluster] [--nomapred] [--rows=ROWS] command nclients
{code}
I believe LoadTester.java generates load for multiple column families (provided
there is an external properties file to define the CFs and their definition,
read/write threads, regions/server) where as PerformanceEvaluation uses only
one CF (TestTable:info).
How does LoadTester differ from YCSB, i believe YCSB supports only one CF as
well.
I think LoadTester can be used for burn-in test (when we provision a new
cluster and sniff the cluster).
If no one is working on this issue, i can help porting loadtest to
src/test/java/org/apache/hadoop/hbase/loadtest.
Thanks.
CRUD Verify Utility
---
Key: HBASE-4917
URL: https://issues.apache.org/jira/browse/HBASE-4917
Project: HBase
Issue Type: Sub-task
Components: client, regionserver
Reporter: Nicolas Spiegelberg
Fix For: 0.94.0
Add a verify utility to run basic CRUD tests against hbase in various common
use cases. This is great for sanity checking a cluster setup because it can
be run as a one line shell command with no required params. Multiple column
families for different use-cases can be tested together. Currently provided
use-cases are 'action log', 'snapshot' and 'search'. The interface is
developed such that it can be easily extended to cover more use-cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4917) CRUD Verify Utility
[ https://issues.apache.org/jira/browse/HBASE-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193532#comment-13193532 ] Mubarak Seyed commented on HBASE-4917: -- working on this port, will attach the patch once i get the corporate approval. Thanks. CRUD Verify Utility --- Key: HBASE-4917 URL: https://issues.apache.org/jira/browse/HBASE-4917 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Fix For: 0.94.0 Add a verify utility to run basic CRUD tests against hbase in various common use cases. This is great for sanity checking a cluster setup because it can be run as a one line shell command with no required params. Multiple column families for different use-cases can be tested together. Currently provided use-cases are 'action log', 'snapshot' and 'search'. The interface is developed such that it can be easily extended to cover more use-cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192349#comment-13192349 ] Mubarak Seyed commented on HBASE-4720: -- Sure, will do. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.trunk.v4.patch, HBASE-4720.trunk.v5.patch, HBASE-4720.trunk.v6.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5273) Provide a coprocessor template for fast development and testing
[ https://issues.apache.org/jira/browse/HBASE-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192642#comment-13192642 ] Mubarak Seyed commented on HBASE-5273: -- It will be nice if we build a example project (some valid coprocessor use-case) and add it under src/examples. Provide a coprocessor template for fast development and testing --- Key: HBASE-5273 URL: https://issues.apache.org/jira/browse/HBASE-5273 Project: HBase Issue Type: Improvement Components: coprocessors Affects Versions: 0.92.0 Reporter: Mingjie Lai Priority: Minor Fix For: 0.94.0 While reworking on the coprocessor blog, I start to realize that we should have a template of coprocessor that helps users to quickly start to develop, test a customized coprocessors. Currently there are some built-in coprocessors but all over the code base, and a user has to search around the code to see how to develop a new one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4913) Per-CF compaction Via the Shell
[ https://issues.apache.org/jira/browse/HBASE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190576#comment-13190576 ] Mubarak Seyed commented on HBASE-4913: -- Please ignore the patch HBASE-4913.trunk.v2.patch, while attaching a file it was failed. Thanks. Per-CF compaction Via the Shell --- Key: HBASE-4913 URL: https://issues.apache.org/jira/browse/HBASE-4913 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4913.trunk.v1.patch, HBASE-4913.trunk.v2.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4913) Per-CF compaction Via the Shell
[ https://issues.apache.org/jira/browse/HBASE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190206#comment-13190206 ] Mubarak Seyed commented on HBASE-4913: -- Working on corporate approval to contribute this patch. Thanks. Per-CF compaction Via the Shell --- Key: HBASE-4913 URL: https://issues.apache.org/jira/browse/HBASE-4913 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Fix For: 0.94.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4913) Per-CF compaction Via the Shell
[ https://issues.apache.org/jira/browse/HBASE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187933#comment-13187933 ] Mubarak Seyed commented on HBASE-4913: -- @Nicolas, If no one is working on this issue, can i take it and port from 89-fb? Please let me know. Thanks. Per-CF compaction Via the Shell --- Key: HBASE-4913 URL: https://issues.apache.org/jira/browse/HBASE-4913 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Fix For: 0.94.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4770) Enable per column family compaction for a region via hbase shell
[ https://issues.apache.org/jira/browse/HBASE-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187943#comment-13187943 ] Mubarak Seyed commented on HBASE-4770: -- @Pritam / @Nicolas, If no one is working on this issue, can i take it up and port it to trunk? Thanks. Enable per column family compaction for a region via hbase shell Key: HBASE-4770 URL: https://issues.apache.org/jira/browse/HBASE-4770 Project: HBase Issue Type: Improvement Affects Versions: 0.94.0 Reporter: Nicolas Spiegelberg Assignee: Pritam Damania Priority: Minor Pretty self-explanatory. We have per-table per-region compaction. However, there are use cases where you have 10+ column families. It is useful to be able to specify the actual CF you wish to compact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4913) Per-CF compaction Via the Shell
[ https://issues.apache.org/jira/browse/HBASE-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13188067#comment-13188067 ] Mubarak Seyed commented on HBASE-4913: -- Working on port, will attach a patch. Thanks. Per-CF compaction Via the Shell --- Key: HBASE-4913 URL: https://issues.apache.org/jira/browse/HBASE-4913 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Fix For: 0.94.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5189) Add metrics to keep track of region-splits in RS
[ https://issues.apache.org/jira/browse/HBASE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13186062#comment-13186062 ] Mubarak Seyed commented on HBASE-5189: -- Waiting for corporate approval to contribute this patch. Thanks. Add metrics to keep track of region-splits in RS Key: HBASE-5189 URL: https://issues.apache.org/jira/browse/HBASE-5189 Project: HBase Issue Type: Improvement Components: metrics, regionserver Affects Versions: 0.92.0, 0.90.5 Reporter: Mubarak Seyed Assignee: Mubarak Seyed Priority: Minor Labels: noob For write-heavy workload with region-size 1 GB, region-split is considerably high. We do normally grep the NN log (grep mkdir*.split NN.log | sort | uniq -c) to get the count. I would like to have a counter incremented each time region-split execution succeeds and this counter exposed via the metrics stuff in HBase. - regionSplitSuccessCount - regionSplitFailureCount (will help us to correlate the timestamp range in RS logs across all RS) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5181) Improve error message when Master fail-over happens and ZK unassigned node contains stale znode(s)
[
https://issues.apache.org/jira/browse/HBASE-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184478#comment-13184478
]
Mubarak Seyed commented on HBASE-5181:
--
Working on corporate approval to contribute this patch. Thanks.
Improve error message when Master fail-over happens and ZK unassigned node
contains stale znode(s)
--
Key: HBASE-5181
URL: https://issues.apache.org/jira/browse/HBASE-5181
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.92.0, 0.90.5
Reporter: Mubarak Seyed
Priority: Minor
Labels: noob
When master fail-over happens, if we have number of RITs under
/hbase/unassigned and if we have stale znode(s) (encoded region names) under
/hbase/unassigned, we are getting
{code}
2011-12-30 10:27:35,623 INFO org.apache.hadoop.hbase.master.HMaster: Master
startup proceeding: master failover
2011-12-30 10:27:36,002 INFO
org.apache.hadoop.hbase.master.AssignmentManager: Failed-over master needs to
process 1717 regions in transition
2011-12-30 10:27:36,004 FATAL org.apache.hadoop.hbase.master.HMaster:
Unhandled exception. Starting shutdown.
java.lang.ArrayIndexOutOfBoundsException: -256
at
org.apache.hadoop.hbase.executor.RegionTransitionData.readFields(RegionTransitionData.java:148)
at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:105)
at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:75)
at
org.apache.hadoop.hbase.executor.RegionTransitionData.fromBytes(RegionTransitionData.java:198)
at org.apache.hadoop.hbase.zookeeper.ZKAssign.getData(ZKAssign.java:743)
at
org.apache.hadoop.hbase.master.AssignmentManager.processRegionInTransition(AssignmentManager.java:262)
at
org.apache.hadoop.hbase.master.AssignmentManager.processFailover(AssignmentManager.java:223)
at
org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:401)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:283)
{code}
and there is no clue on how to clean-up the stale znode(s) from unassigned
using zkCli.sh (del /hbase/unassigned/bad region name). It would be good if
we include the bad region name in IOException from
RegionTransitionData.readFields().
{code}
@Override
public void readFields(DataInput in) throws IOException {
// the event type byte
eventType = EventType.values()[in.readShort()];
// the timestamp
stamp = in.readLong();
// the encoded name of the region being transitioned
regionName = Bytes.readByteArray(in);
// remaining fields are optional so prefixed with boolean
// the name of the regionserver sending the data
if (in.readBoolean()) {
byte [] versionedBytes = Bytes.readByteArray(in);
this.origin = ServerName.parseVersionedServerName(versionedBytes);
}
if (in.readBoolean()) {
this.payload = Bytes.readByteArray(in);
}
}
{code}
If the code execution has survived until regionName then we can include the
regionName in IOException with error message to clean-up the stale znode(s)
under /hbase/unassigned.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5181) Improve error message when Master fail-over happens and ZK unassigned node contains stale znode(s)
[
https://issues.apache.org/jira/browse/HBASE-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184514#comment-13184514
]
Mubarak Seyed commented on HBASE-5181:
--
Is there any suggestion on error message? How about
throw new IOException(There could be a stale region-in-transition in ZK. +
The bad region is + Bytes.toString(regionName) +
. Try deleting the region-in-transition using 'del
/hbase/unassigned/
+ Bytes.toString(regionName) + ' command over a ZK
connection (in zkCli.sh), ioe);
Improve error message when Master fail-over happens and ZK unassigned node
contains stale znode(s)
--
Key: HBASE-5181
URL: https://issues.apache.org/jira/browse/HBASE-5181
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.92.0, 0.90.5
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
Labels: noob
When master fail-over happens, if we have number of RITs under
/hbase/unassigned and if we have stale znode(s) (encoded region names) under
/hbase/unassigned, we are getting
{code}
2011-12-30 10:27:35,623 INFO org.apache.hadoop.hbase.master.HMaster: Master
startup proceeding: master failover
2011-12-30 10:27:36,002 INFO
org.apache.hadoop.hbase.master.AssignmentManager: Failed-over master needs to
process 1717 regions in transition
2011-12-30 10:27:36,004 FATAL org.apache.hadoop.hbase.master.HMaster:
Unhandled exception. Starting shutdown.
java.lang.ArrayIndexOutOfBoundsException: -256
at
org.apache.hadoop.hbase.executor.RegionTransitionData.readFields(RegionTransitionData.java:148)
at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:105)
at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:75)
at
org.apache.hadoop.hbase.executor.RegionTransitionData.fromBytes(RegionTransitionData.java:198)
at org.apache.hadoop.hbase.zookeeper.ZKAssign.getData(ZKAssign.java:743)
at
org.apache.hadoop.hbase.master.AssignmentManager.processRegionInTransition(AssignmentManager.java:262)
at
org.apache.hadoop.hbase.master.AssignmentManager.processFailover(AssignmentManager.java:223)
at
org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:401)
at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:283)
{code}
and there is no clue on how to clean-up the stale znode(s) from unassigned
using zkCli.sh (del /hbase/unassigned/bad region name). It would be good if
we include the bad region name in IOException from
RegionTransitionData.readFields().
{code}
@Override
public void readFields(DataInput in) throws IOException {
// the event type byte
eventType = EventType.values()[in.readShort()];
// the timestamp
stamp = in.readLong();
// the encoded name of the region being transitioned
regionName = Bytes.readByteArray(in);
// remaining fields are optional so prefixed with boolean
// the name of the regionserver sending the data
if (in.readBoolean()) {
byte [] versionedBytes = Bytes.readByteArray(in);
this.origin = ServerName.parseVersionedServerName(versionedBytes);
}
if (in.readBoolean()) {
this.payload = Bytes.readByteArray(in);
}
}
{code}
If the code execution has survived until regionName then we can include the
regionName in IOException with error message to clean-up the stale znode(s)
under /hbase/unassigned.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184647#comment-13184647
]
Mubarak Seyed commented on HBASE-4720:
--
This patch does not cover the following from Andrew's comments:
{quote}
The REST gateway does support a batch put operation, where the supplied model
contains multiple rows. The request URI will contain the table name and a row
key, but the row key would be ignored and should be set to something known not
to exist, like submit. (Row name in the model takes preference to whatever
was supplied in the URI.) See RowResource, starting around line 160. This gives
the client the option of submitting work in batch, to reduce overheads.
So optionally here you could retrieve a list of rows and process them, building
a response that includes the disposition of each.
{quote}
[HTable.checkAndPut|http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html]
and
[HTable.checkAndDelete|http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html]
API supports only one row at a time. I don't think we need to support batch of
checkAndPut and checkAndDelete.
{quote}
The URI format for requests is '/table/row/ ...' This violates that by
adding, just for check-and cases, a prefix. Having a special case like that
should be avoided. What about handling this in TableResource, with a query
parameter? '/table/row/?check' E.g.Then you won't need
CheckAndXTableResource classes. Additionally use the appropriate HTTP
operations. PUT/POST for check-and-put. DELETE for check-and-delete. The spec
does not forbid bodies in DELETE requests. (I am unsure if Jetty/Jersey will
support it however.)
{quote}
We have discussed the design choices earlier (refer comments in the same JIRA),
Stack and Ted have voted for option # 2 (/checkandput, /checkanddelete) option.
If i have to go back to option #1 then i will have to re-work most of the stuff
here.
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch,
HBASE-4720.trunk.v3.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184694#comment-13184694 ] Mubarak Seyed commented on HBASE-4720: -- My local tests were keep failing on trunk, will fix the TestRowResource. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-2182) NIO based RPC
[ https://issues.apache.org/jira/browse/HBASE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174701#comment-13174701 ] Mubarak Seyed commented on HBASE-2182: -- Netty 3.2 ([NETTY-293|https://issues.jboss.org/browse/NETTY-293]) supports sendfile() system call. NIO based RPC - Key: HBASE-2182 URL: https://issues.apache.org/jira/browse/HBASE-2182 Project: HBase Issue Type: Improvement Components: ipc, performance Reporter: Andrew Purtell Assignee: ryan rawson Reimplement HBase RPC with an NIO framework. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3565) Add a metric to keep track of slow HLog appends
[
https://issues.apache.org/jira/browse/HBASE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175163#comment-13175163
]
Mubarak Seyed commented on HBASE-3565:
--
IMO we need 4 metrics
1. slowHLogAppendsCount (AtomicLong, increment by 1 whenever it takes 1 sec
to append HLog, no reset, long-live until RS runs)
2. minHLogAppendTime (when we log slow appends 1 sec)
3. avgHLogAppendTime
4. maxHLogAppendTime
2, 3, and 4 are needs to get reset upon every doUpdate() for every 5 minutes or
so. For every 5 minutes, we will get 1 min/avg/max HLog append time.
Add a metric to keep track of slow HLog appends
---
Key: HBASE-3565
URL: https://issues.apache.org/jira/browse/HBASE-3565
Project: HBase
Issue Type: Improvement
Components: metrics, regionserver
Reporter: Benoit Sigoure
Labels: monitoring
Whenever an edit takes too long to be written to an HLog, HBase logs a
warning such as this one:
{code}
2011-02-23 20:03:14,703 WARN org.apache.hadoop.hbase.regionserver.wal.HLog:
IPC Server handler 21 on 60020 took 15065ms appending an edit to hlog;
editcount=126050
{code}
I would like to have a counter incremented each time this happens and this
counter exposed via the metrics stuff in HBase so I can collect it in my
monitoring system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3565) Add a metric to keep track of slow HLog appends
[
https://issues.apache.org/jira/browse/HBASE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175169#comment-13175169
]
Mubarak Seyed commented on HBASE-3565:
--
I guess metric names are confusing. How about
slowHLogAppendCount
slowHLogAppendMinTime
slowHLogAppendAvgTime
slowHLogAppendMaxTime
Add a metric to keep track of slow HLog appends
---
Key: HBASE-3565
URL: https://issues.apache.org/jira/browse/HBASE-3565
Project: HBase
Issue Type: Improvement
Components: metrics, regionserver
Reporter: Benoit Sigoure
Labels: monitoring
Whenever an edit takes too long to be written to an HLog, HBase logs a
warning such as this one:
{code}
2011-02-23 20:03:14,703 WARN org.apache.hadoop.hbase.regionserver.wal.HLog:
IPC Server handler 21 on 60020 took 15065ms appending an edit to hlog;
editcount=126050
{code}
I would like to have a counter incremented each time this happens and this
counter exposed via the metrics stuff in HBase so I can collect it in my
monitoring system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3565) Add a metric to keep track of slow HLog appends
[
https://issues.apache.org/jira/browse/HBASE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175200#comment-13175200
]
Mubarak Seyed commented on HBASE-3565:
--
slowHLogAppendCount
slowHLogAppendTime
-slowHLogAppendMinTime-
-slowHLogAppendAvgTime-
-slowHLogAppendMaxTime-
Waiting for corporate approval to contribute this patch. Thanks.
Add a metric to keep track of slow HLog appends
---
Key: HBASE-3565
URL: https://issues.apache.org/jira/browse/HBASE-3565
Project: HBase
Issue Type: Improvement
Components: metrics, regionserver
Reporter: Benoit Sigoure
Labels: monitoring
Whenever an edit takes too long to be written to an HLog, HBase logs a
warning such as this one:
{code}
2011-02-23 20:03:14,703 WARN org.apache.hadoop.hbase.regionserver.wal.HLog:
IPC Server handler 21 on 60020 took 15065ms appending an edit to hlog;
editcount=126050
{code}
I would like to have a counter incremented each time this happens and this
counter exposed via the metrics stuff in HBase so I can collect it in my
monitoring system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175233#comment-13175233 ] Mubarak Seyed commented on HBASE-4720: -- Thanks Ted and Stack. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174345#comment-13174345
]
Mubarak Seyed commented on HBASE-4720:
--
@Ted:
{{eclipse_formatter_apache.xml}} does not work for long lines. Do you mind to
post your eclipse formatter rule file? Thanks.
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.v1.patch,
HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174517#comment-13174517
]
Mubarak Seyed commented on HBASE-4720:
--
I addressed most of the review comments, will wait until get more review
comments from Andrew (and others).
{code}
parameter update is not being used in other places as well.
RowResoure.java:
Response update(final CellSetModel model, final boolean replace)
Response updateBinary(final byte[] message, final HttpHeaders headers,
final boolean replace)
ScannerResource.java:
-
Response update(final ScannerModel model, final boolean replace,
final UriInfo uriInfo) {
{code}
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.v1.patch,
HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4151) completebulkload checks zoo.cfg even though ZK ensemble is specified in hbase-site.xml
[
https://issues.apache.org/jira/browse/HBASE-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174564#comment-13174564
]
Mubarak Seyed commented on HBASE-4151:
--
Waiting for corporate approval to contribute this patch. Thanks.
completebulkload checks zoo.cfg even though ZK ensemble is specified in
hbase-site.xml
--
Key: HBASE-4151
URL: https://issues.apache.org/jira/browse/HBASE-4151
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.90.1
Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Labels: hbase
I have generated HFiles using importtsv and tried to bulk load them using
completebulkload, even though i have specified the ZK quorum ensemble and
client port in hbase-site.xml, completebulkload looks for ZK ensemble and
client port in zoo.cfg, even after i have specified parameters in zoo.cfg, i
was getting NullPointerException at line 167 in ZKConfig.java
{code}
if
(conf.get(HConstants.CLUSTER_DISTRIBUTED).equals(HConstants.CLUSTER_IS_DISTRIBUTED)
value.startsWith(localhost)) {
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173567#comment-13173567
]
Mubarak Seyed commented on HBASE-4720:
--
when i ran the tests, it fails at
{code}
Running org.apache.hadoop.hbase.util.TestRegionSplitCalculator
Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.077 sec
FAILURE!
Failed tests:
testSplitCalculatorEq(org.apache.hadoop.hbase.util.TestRegionSplitCalculator):
expected:2 but was:1
{code}
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.v1.patch, HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173914#comment-13173914
]
Mubarak Seyed commented on HBASE-4720:
--
Thanks Stack.
bq. Suggest you not do stuff like below in future because it bloats your patch
making it more susceptible to rot and besides is not related directly to what
you are trying to your fix so distracting for reviewers (for the next time):
I had formatted the code using
[-HBASE-3678-|https://issues.apache.org/jira/browse/HBASE-3678]
{{eclipse_formatter_apache.xml}}. I apologize for messing up with format. Can
you please advice on code formatting? (i believe hbase book also refers
HBASE-3678 for code formatting)
bq. Is this safe? e.g. what if row has binary characters in it? Should these be
base64'd or something?
Other test methods in
{{src/test/java/org/apache/hadoop/hbase/rest/TestRowResources.java}} uses the
same way to build the URI ({{deleteRow, deleteValue, putValuePB,}} etc). I just
copied the code from other methods.
bq. You have some lines that are way too long.
{{eclipse-code-formatter.xml}} uses line length as 80, please advice on line
length.
{code}
setting id=org.eclipse.jdt.core.formatter.comment.line_length value=80/
{code}
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Assignee: Mubarak Seyed
Fix For: 0.94.0
Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.v1.patch,
HBASE-4720.v3.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172743#comment-13172743 ] Mubarak Seyed commented on HBASE-4720: -- Thanks Ted. I am done with refactor the code/unit-tests. Once unit test (with runLargeTests) ran, will update the diff to review board and update the patch here. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Attachments: HBASE-4720.v1.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172758#comment-13172758 ] Mubarak Seyed commented on HBASE-4720: -- Regarding unit test classes, i dont need separate TestResource.java as checkAndPut/checkAndDelete are related to RowResource. I just added few test methods in RowResource, is that ok? or do i need to create separate TestCheckAndPutResource.java/TestCheckAndDeleteResource.java? Please confirm. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.v1.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172879#comment-13172879 ] Mubarak Seyed commented on HBASE-4720: -- Uploaded the patch (HBASE-4720.v3.patch) to review board https://reviews.apache.org/r/3250/diff/2/ Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172986#comment-13172986 ] Mubarak Seyed commented on HBASE-4720: -- This JIRA request was opened by my colleague as we need this feature in 0.90 branch as we have a requirement to use atomic update operations in production cluster. If this fix goes only in 0.92 and TRUNK then we need to wait a while. Can't we apply this patch under 0.90.6 branch? I can create a separate patch for 0.92 and TRUNK. Please confirm. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172991#comment-13172991 ] Mubarak Seyed commented on HBASE-4720: -- Okay, i will work on patch for TRUNK then. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Assignee: Mubarak Seyed Fix For: 0.94.0 Attachments: HBASE-4720.v1.patch, HBASE-4720.v3.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171319#comment-13171319 ] Mubarak Seyed commented on HBASE-4720: -- Sure, will refactor and post it on review board. Thanks. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Attachments: HBASE-4720.v1.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[
https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171436#comment-13171436
]
Mubarak Seyed commented on HBASE-4720:
--
Thanks Ted. This is what i think about refactoring the TableResource and
CheckAndResource.
I can't extend from TableResource as WebContainer ends up look for @Path in
TableResource after calling super(table) in CheckAndResource, which causes
web container to throw incorrect URI exception.
Even if i make some of the methods (scanTransformAttrs) to static, it breaks on
variables scope.
I think we need a superClass for both TableResource and CheckAndResource,
which can carry most of the methods (scanTransformAttrs, getTransform,
setTransform, tranform), it would look like
{code}
public class BasicResource extends ResourceBase{
-- All the common methods --
}
public class TableResource extends BasicResource{
}
public class CheckAndResource extends BasicResource{
}
{code}
OR we can move all the common methods to ResourceBase and we can have
overloaded constructor to send table name, like
{code}
public ResourceBase(String table){
}
public ResourceBase(){
}
{code}
so that all other resource classes (such as VersionResource, SchemaResource,
etc) does not need to change.
I am just hacking the code with option #2 (moving methods to ResourceBase),
will test it out, post them on review board then wait for comments.
Thanks,
Mubarak
Implement atomic update operations (checkAndPut, checkAndDelete) for REST
client/server
Key: HBASE-4720
URL: https://issues.apache.org/jira/browse/HBASE-4720
Project: HBase
Issue Type: Improvement
Reporter: Daniel Lord
Attachments: HBASE-4720.v1.patch
I have several large application/HBase clusters where an application node
will occasionally need to talk to HBase from a different cluster. In order
to help ensure some of my consistency guarantees I have a sentinel table that
is updated atomically as users interact with the system. This works quite
well for the regular hbase client but the REST client does not implement
the checkAndPut and checkAndDelete operations. This exposes the application
to some race conditions that have to be worked around. It would be ideal if
the same checkAndPut/checkAndDelete operations could be supported by the REST
client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server
[ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171473#comment-13171473 ] Mubarak Seyed commented on HBASE-4720: -- Code is posted at https://reviews.apache.org/r/3250/ for review. Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server Key: HBASE-4720 URL: https://issues.apache.org/jira/browse/HBASE-4720 Project: HBase Issue Type: Improvement Reporter: Daniel Lord Attachments: HBASE-4720.v1.patch I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster. In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system. This works quite well for the regular hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations. This exposes the application to some race conditions that have to be worked around. It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4909) Detailed Block Cache Metrics
[ https://issues.apache.org/jira/browse/HBASE-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171474#comment-13171474 ] Mubarak Seyed commented on HBASE-4909: -- If no one is working on this issue, i can help porting from 89-fb. Thanks. Detailed Block Cache Metrics Key: HBASE-4909 URL: https://issues.apache.org/jira/browse/HBASE-4909 Project: HBase Issue Type: Sub-task Components: client, regionserver Reporter: Nicolas Spiegelberg Fix For: 0.94.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection
[
https://issues.apache.org/jira/browse/HBASE-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170029#comment-13170029
]
Mubarak Seyed commented on HBASE-4893:
--
Yup, all tests were passed in 0.90.5. This is for 0.90.5. Thanks.
HConnectionImplementation closed-but-not-deleted, need a way to find the
state of connection
Key: HBASE-4893
URL: https://issues.apache.org/jira/browse/HBASE-4893
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.1
Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.90.5
Attachments: HBASE-4893.v1.patch
In abort() of HConnectionManager$HConnectionImplementation, instance of
HConnectionImplementation is marked as this.closed=true.
There is no way for client application to check the hbase client connection
whether it is still opened/good (this.closed=false) or not. We need a method
to validate the state of a connection like isClosed().
{code}
public boolean isClosed(){
return this.closed;
}
{code}
Once the connection is closed and it should get deleted. Client application
still gets a connection from HConnectionManager.getConnection(Configuration)
and tries to make a RPC call to RS, since connection is already closed,
HConnectionImplementation.getRegionServerWithRetries throws
RetriesExhaustedException with error message
{code}
Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying
to contact region server null for region , row
'----xxx', but failed after 10 attempts.
Exceptions:
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection
[
https://issues.apache.org/jira/browse/HBASE-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170441#comment-13170441
]
Mubarak Seyed commented on HBASE-4893:
--
If we keep this.closed=true, after removing the key from HBASE_INSTANCES map,
connection.close(stopProxy) is getting called, since it is already marked as
closed, close(stopProxy) will not stop the proxy for Master/RS and will not
close the ZK connection.
{code}
void close(boolean stopProxy) {
if (this.closed) {
return;
}
..
..
}
{code}
Will submit a patch.
HConnectionImplementation closed-but-not-deleted, need a way to find the
state of connection
Key: HBASE-4893
URL: https://issues.apache.org/jira/browse/HBASE-4893
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.1
Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.90.5
Attachments: HBASE-4893.v1.patch
In abort() of HConnectionManager$HConnectionImplementation, instance of
HConnectionImplementation is marked as this.closed=true.
There is no way for client application to check the hbase client connection
whether it is still opened/good (this.closed=false) or not. We need a method
to validate the state of a connection like isClosed().
{code}
public boolean isClosed(){
return this.closed;
}
{code}
Once the connection is closed and it should get deleted. Client application
still gets a connection from HConnectionManager.getConnection(Configuration)
and tries to make a RPC call to RS, since connection is already closed,
HConnectionImplementation.getRegionServerWithRetries throws
RetriesExhaustedException with error message
{code}
Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying
to contact region server null for region , row
'----xxx', but failed after 10 attempts.
Exceptions:
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection
[
https://issues.apache.org/jira/browse/HBASE-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170472#comment-13170472
]
Mubarak Seyed commented on HBASE-4893:
--
close(boolean stopProxy) already sets this.closed=true. close(stopProxy) will
be called after removing the key from HBASE_INSTANCES map.
HConnectionImplementation closed-but-not-deleted, need a way to find the
state of connection
Key: HBASE-4893
URL: https://issues.apache.org/jira/browse/HBASE-4893
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.1
Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.90.5
Attachments: HBASE-4893.v1.patch
In abort() of HConnectionManager$HConnectionImplementation, instance of
HConnectionImplementation is marked as this.closed=true.
There is no way for client application to check the hbase client connection
whether it is still opened/good (this.closed=false) or not. We need a method
to validate the state of a connection like isClosed().
{code}
public boolean isClosed(){
return this.closed;
}
{code}
Once the connection is closed and it should get deleted. Client application
still gets a connection from HConnectionManager.getConnection(Configuration)
and tries to make a RPC call to RS, since connection is already closed,
HConnectionImplementation.getRegionServerWithRetries throws
RetriesExhaustedException with error message
{code}
Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying
to contact region server null for region , row
'----xxx', but failed after 10 attempts.
Exceptions:
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4893) HConnectionImplementation is closed but not deleted
[
https://issues.apache.org/jira/browse/HBASE-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170493#comment-13170493
]
Mubarak Seyed commented on HBASE-4893:
--
Thanks Zhihong Yu. One basic question: Do i need to merge the fix into 0.92?
Thanks.
HConnectionImplementation is closed but not deleted
---
Key: HBASE-4893
URL: https://issues.apache.org/jira/browse/HBASE-4893
Project: HBase
Issue Type: Bug
Components: client
Affects Versions: 0.90.1
Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
Labels: noob
Fix For: 0.90.6
Attachments: HBASE-4893.v1.patch, HBASE-4893.v2.patch
In abort() of HConnectionManager$HConnectionImplementation, instance of
HConnectionImplementation is marked as this.closed=true.
There is no way for client application to check the hbase client connection
whether it is still opened/good (this.closed=false) or not. We need a method
to validate the state of a connection like isClosed().
{code}
public boolean isClosed(){
return this.closed;
}
{code}
Once the connection is closed and it should get deleted. Client application
still gets a connection from HConnectionManager.getConnection(Configuration)
and tries to make a RPC call to RS, since connection is already closed,
HConnectionImplementation.getRegionServerWithRetries throws
RetriesExhaustedException with error message
{code}
Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying
to contact region server null for region , row
'----xxx', but failed after 10 attempts.
Exceptions:
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
java.io.IOException:
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@7eab48a7
closed
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.java:1008)
at org.apache.hadoop.hbase.client.HTable.get(HTable.java:546)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
