[jira] [Updated] (HBASE-5669) AggregationClient fails validation for open stoprow scan

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5669:
-

Attachment: HBASE-5669.trunk.v1.patch

The attached file is a patch. Thanks.

 AggregationClient fails validation for open stoprow scan
 

 Key: HBASE-5669
 URL: https://issues.apache.org/jira/browse/HBASE-5669
 Project: HBase
  Issue Type: Bug
  Components: coprocessors
Affects Versions: 0.92.1
 Environment: n/a
Reporter: Brian Rogers
Priority: Minor
 Fix For: 0.92.2

 Attachments: HBASE-5669.trunk.v1.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 AggregationClient.validateParameters throws an exception when the Scan has a 
 valid startrow but an unset endrow.

--
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] [Updated] (HBASE-5675) Create table fails if we keep refreshing master's UI for task monitor status

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5675:
-

Affects Version/s: 0.94.0
   0.92.0

 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] [Updated] (HBASE-4913) Per-CF compaction Via the Shell

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4913:
-

Fix Version/s: (was: 0.94.0)
   0.96.0

 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.96.0

 Attachments: HBASE-4913.trunk.v1.patch, HBASE-4913.trunk.v2.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] [Updated] (HBASE-5504) Online Merge

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5504:
-

Issue Type: Brainstorming  (was: New Feature)

Design will be evolved.

 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] [Updated] (HBASE-5504) Online Merge

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5504:
-

Labels:   (was: noob)

 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] [Updated] (HBASE-5434) [REST] Include more metrics in cluster status request

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5434:
-

Attachment: HBASE-5434.trunk.v2.patch

The attached file is an updated patch (with fix for unit test failure)

There was an incorrect Protobuf base64 encoded string
{code}
-  private static final String AS_PB =
-Ci0KBXRlc3QxEOO6i+eeJBgAIIABKIAIMhUKCS1ST09ULSwsMBABGAEgACgAMAAKOQoFdGVzdDIQ+
-/pKx8J4kGAAggAQogAgyIQoVLk1FVEEuLCwxMjQ2MDAwMDQzNzI0EAEYASAAKAAwABgCIAAp+
-8D8=;
-
+  private static final String AS_PB =
+  
CjsKBXRlc3QxEOO6i+eeJBgAIIABKIAIMiMKCS1ST09ULSwsMBABGAEgACgAMAA4AUACSAFQAVgB +
+  
YAFoAQpHCgV0ZXN0MhD+krHwniQYACCABCiACDIvChUuTUVUQS4sLDEyNDYwMDAwNDM3MjQQARgB +
+  IAAoADAAOAFAAkgBUAFYAWABaAEYAiAAKQAAAPA/;
{code}

Unit tested all the rest test code.

{code}
mvn -e -up clean test - Dtest=org.apache.hadoop.hbase.rest.* 

Results :

Tests run: 51, Failures: 0, Errors: 0, Skipped: 0
{code}

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, 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] [Updated] (HBASE-5434) [REST] Include more metrics in cluster status request

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5434:
-

Attachment: HBASE-5434.trunk.v1.patch

The attached file is a patch.
Unit tests are passed. Tested in 5 node dev cluster. 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] [Updated] (HBASE-4991) Provide capability to delete named region

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4991:
-

Attachment: HBASE-4991.trunk.v1.patch

The attached file is a patch. 
Code review request at https://reviews.apache.org/r/3909/

 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


 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] [Updated] (HBASE-5283) Request counters may become negative for heavily loaded regions

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5283:
-

Attachment: HBASE-5283.trunk.v1.patch

The attached file is a patch.

 Request counters may become negative for heavily loaded regions
 ---

 Key: HBASE-5283
 URL: https://issues.apache.org/jira/browse/HBASE-5283
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
Assignee: Mubarak Seyed
 Fix For: 0.94.0, 0.92.1

 Attachments: HBASE-5283.trunk.v1.patch


 Requests counter showing negative count, example under 'Requests' column: 
 -645470239
 {code}
 Name  Region Server   Start Key   End Key Requests
 usertable,user2037516127892189021,1326756873774.16833e4566d1daef109b8fdcd1f4b5a6.
  xxx.com:60030   user2037516127892189021 user2296868939942738705  
-645470239
 {code}
 RegionLoad.readRequestsCount and RegionLoad.writeRequestsCount are of int 
 type. Our Ops has been running lots of heavy load operation. 
 RegionLoad.getRequestsCount() overflows int.MAX_VALUE. It is set to D986E7E1. 
 In table.jsp, RegionLoad.getRequestsCount() is assigned to long type. 
 D986E7E1 is converted to long D986E7E1 which is -645470239 in decimal.
 Suggested fix is to make readRequestsCount and writeRequestsCount long type. 

--
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] [Updated] (HBASE-3859) Increment a counter when a Scanner lease expires

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-3859:
-

Attachment: HBASE-3859.trunk.v1.patch

The attached file is a patch. 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v7.patch

The attached file (HBASE-4720.trunk.v7.patch)   addresses option # 1 to add 
query param /table/row?check=put or /table/row?check=delete

@Andrew
Can you please review the changes?

 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] [Updated] (HBASE-4940) hadoop-metrics.properties can include configuration of the rest context for ganglia

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4940:
-

Attachment: HBASE-4940.trunk.v2.patch

The attached file (HBASE-4940.trunk.v2.patch)  updates the patch with 
explanation for GMETADHOST_IP

 hadoop-metrics.properties can include configuration of the rest context for 
 ganglia
 -

 Key: HBASE-4940
 URL: https://issues.apache.org/jira/browse/HBASE-4940
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Affects Versions: 0.90.5
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
  Labels: hbase-rest
 Fix For: 0.94.0

 Attachments: HBASE-4940.patch, HBASE-4940.trunk.v1.patch, 
 HBASE-4940.trunk.v2.patch


 It appears from hadoop-metrics.properties that configuration for rest context 
 is missing. It would be good if we add the rest context and commented out 
 them, if anyone is using rest-server and if they want to monitor using 
 ganglia context then they can uncomment the rest context and use them for 
 rest-server monitoring using ganglia.
 {code}
 # Configuration of the rest context for ganglia
 #rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
 #rest.period=10
 #rest.servers=ganglia-metad-hostname:port
 {code}
 Working on the patch, will submit 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v6.patch

The attached file (HBASE-4720.trunk.v6.patch) is updated patch 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.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] [Updated] (HBASE-5189) Add metrics to keep track of region-splits in RS

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5189:
-

Attachment: HBASE-5189.trunk.v2.patch

If we move getMetrics().incrementSplitFailureCount() before rollback() and if 
rollback() returns false (or) throws RuntimeException then we don't need to 
increment split failure count as RS is going to abort itself.

The one place which needs to call getMetrics().incrementSplitFailureCount() is 
catch block

{code}
} catch (IOException ex) {
  LOG.error(Split failed  + this, RemoteExceptionHandler
  .checkIOException(ex));
  this.server.getMetrics().incrementSplitFailureCount();
  server.checkFileSystem();
{code}

as rollback() throws IOException.

The attached patch (HBASE-5189.trunk.v2.patch) updates the 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.90.5, 0.92.0
Reporter: Mubarak Seyed
Assignee: Mubarak Seyed
Priority: Minor
  Labels: noob
 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] [Updated] (HBASE-4913) Per-CF compaction Via the Shell

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4913:
-

Attachment: HBASE-4913.trunk.v2.patch

 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] [Updated] (HBASE-4913) Per-CF compaction Via the Shell

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4913:
-

Attachment: HBASE-4913.trunk.v2.patch

The attached file (HBASE-4913.trunk.v2.patch) is updated patch.

{code}
test-test:hbase-trunk-test mubarak$ patch -p0 -i ~/HBASE-4913.trunk.v2.patch 
patching file 
src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
patching file src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
patching file 
src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
patching file src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java
patching file src/main/ruby/hbase/admin.rb
patching file src/main/ruby/shell/commands/compact.rb
patching file src/main/ruby/shell/commands/major_compact.rb
{code}

 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, 
 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v5.patch

The attached patch (HBASE-4720.trunk.v5.patch) rebased on trunk, removed the 
previous refactoring (ResourceBase) and Unit tested.

{code}
test-test:hbase-trunk-test mubarak$ patch -p0 -i ~/HBASE-4720.trunk.v5.patch 
patching file src/test/java/org/apache/hadoop/hbase/rest/TestRowResource.java
patching file 
src/main/java/org/apache/hadoop/hbase/rest/CheckAndPutTableResource.java
patching file 
src/main/java/org/apache/hadoop/hbase/rest/CheckAndPutRowResource.java
patching file 
src/main/java/org/apache/hadoop/hbase/rest/CheckAndDeleteTableResource.java
patching file 
src/main/java/org/apache/hadoop/hbase/rest/CheckAndDeleteRowResource.java
patching file src/main/java/org/apache/hadoop/hbase/rest/RootResource.java
patching file 
src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java
{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.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] [Updated] (HBASE-5189) Add metrics to keep track of region-splits in RS

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5189:
-

Attachment: HBASE-5189.trunk.v1.patch

The attached file is a patch.

 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
 Attachments: HBASE-5189.trunk.v1.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] [Updated] (HBASE-4913) Per-CF compaction Via the Shell

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4913:
-

Attachment: HBASE-4913.trunk.v1.patch

The attached file is 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

 Attachments: HBASE-4913.trunk.v1.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] [Updated] (HBASE-5181) Improve error message when Master fail-over happens and ZK unassigned node contains stale znode(s)

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-5181:
-

Attachment: HBASE-5181-v1-trunk.patch

The attached file is a patch.

 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
 Attachments: HBASE-5181-v1-trunk.patch


 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v3.patch

The attached file (HBASE-4720.trunk.v3.patch) contains changes for Andrew 
Purtell's code review comments.

This patch does not cover the following from Andrew's comments:

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.

HTable.checkAndPut and HTable.checkAndDelete
API supports only one row at a time 
(http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#checkAndPut(byte[],
 byte[], byte[], byte[], org.apache.hadoop.hbase.client.Put)). I don't think we 
need to support batch of checkAndPut and checkAndDelete.

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.)

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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v4.patch

Tests were still failing for runMediumTests on trunk but i have fixed the 
TestRowResource. The attached file (HBASE-4720.trunk.v4.patch) is a latest 
patch. Thanks.

{code}
mvn clean test -P runMediumTests -Dtest=org.apache.hadoop.hbase.rest.*

Running org.apache.hadoop.hbase.rest.TestRowResource
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.099 se
{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.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] [Updated] (HBASE-3565) Add a metric to keep track of slow HLog appends

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-3565:
-

Attachment: HBASE-3565.trunk.v1.patch

The attached file is a patch.

 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
 Attachments: HBASE-3565.trunk.v1.patch


 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] [Updated] (HBASE-4151) completebulkload checks zoo.cfg even though ZK ensemble is specified in hbase-site.xml

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4151:
-

Attachment: HBASE-4151.trunk.v1.patch

The attached file is a patch.

 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.94.0
 Environment: HBase-0.90.1
Reporter: Seyed
Priority: Minor
  Labels: hbase
 Attachments: HBASE-4151.trunk.v1.patch


 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v2.patch

The attached file (HBASE-4720.trunk.v2.patch) addresses most of the code review 
comments.

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.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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v2.patch

Per Ted's request, resubmitting the patch. 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.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] [Updated] (HBASE-4940) hadoop-metrics.properties can include configuration of the rest context for ganglia

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4940:
-

Attachment: HBASE-4940.trunk.v1.patch

The attached file (HBASE-4940.trunk.v1.patch)
is a patch for TRUNK. Thanks.

 hadoop-metrics.properties can include configuration of the rest context for 
 ganglia
 -

 Key: HBASE-4940
 URL: https://issues.apache.org/jira/browse/HBASE-4940
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Affects Versions: 0.90.5
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Priority: Minor
  Labels: hbase-rest
 Fix For: 0.94.0

 Attachments: HBASE-4940.patch, HBASE-4940.trunk.v1.patch


 It appears from hadoop-metrics.properties that configuration for rest context 
 is missing. It would be good if we add the rest context and commented out 
 them, if anyone is using rest-server and if they want to monitor using 
 ganglia context then they can uncomment the rest context and use them for 
 rest-server monitoring using ganglia.
 {code}
 # Configuration of the rest context for ganglia
 #rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
 #rest.period=10
 #rest.servers=ganglia-metad-hostname:port
 {code}
 Working on the patch, will submit 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] [Updated] (HBASE-4151) completebulkload checks zoo.cfg even though ZK ensemble is specified in hbase-site.xml

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4151:
-

 Priority: Minor  (was: Major)
Affects Version/s: (was: 0.90.1)
   0.94.0

 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.94.0
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Priority: Minor
  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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v1.patch

The attached file (HBASE-4720.trunk.v1.patch) contains changes after rebased on 
TRUNK.

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.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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.trunk.v1.patch

Sorry for the inconvenience, i forgot to do 'svn add file' before the patch. 
The attached file contains updated patch. 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.v1.patch, 
 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] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4720:
-

Attachment: HBASE-4720.v3.patch

The attached file (HBASE-4720.v3.patch) contains refactored code with unit 
tests.

 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] [Updated] (HBASE-4940) hadoop-metrics.properties can include configuration of the rest context for ganglia

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4940:
-

Fix Version/s: (was: 0.90.5)
   0.90.6

 hadoop-metrics.properties can include configuration of the rest context for 
 ganglia
 -

 Key: HBASE-4940
 URL: https://issues.apache.org/jira/browse/HBASE-4940
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Affects Versions: 0.90.5
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Priority: Minor
  Labels: hbase-rest
 Fix For: 0.90.6

 Attachments: HBASE-4940.patch


 It appears from hadoop-metrics.properties that configuration for rest context 
 is missing. It would be good if we add the rest context and commented out 
 them, if anyone is using rest-server and if they want to monitor using 
 ganglia context then they can uncomment the rest context and use them for 
 rest-server monitoring using ganglia.
 {code}
 # Configuration of the rest context for ganglia
 #rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
 #rest.period=10
 #rest.servers=ganglia-metad-hostname:port
 {code}
 Working on the patch, will submit 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] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Fix Version/s: (was: 0.90.6)
   0.90.5

 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] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Attachment: HBASE-4893.v2.patch

The attached file HBASE-4893.v2.patch is an updated patch (generated from root 
of the source)

 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, 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

[jira] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Attachment: HBASE-4893.v1.patch

The attached file HBASE-4893.v1.patch is 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.6

 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] [Updated] (HBASE-4940) hadoop-metrics.properties can include configuration of the rest context for ganglia

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4940:
-

Attachment: HBASE-4940.patch

The attached file is a patch

 hadoop-metrics.properties can include configuration of the rest context for 
 ganglia
 -

 Key: HBASE-4940
 URL: https://issues.apache.org/jira/browse/HBASE-4940
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Affects Versions: 0.90.5
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Priority: Minor
  Labels: hbase-rest
 Fix For: 0.90.6

 Attachments: HBASE-4940.patch


 It appears from hadoop-metrics.properties that configuration for rest context 
 is missing. It would be good if we add the rest context and commented out 
 them, if anyone is using rest-server and if they want to monitor using 
 ganglia context then they can uncomment the rest context and use them for 
 rest-server monitoring using ganglia.
 {code}
 # Configuration of the rest context for ganglia
 #rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
 #rest.period=10
 #rest.servers=ganglia-metad-hostname:port
 {code}
 Working on the patch, will submit 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] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Labels: noob  (was: hbase-client)

 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, 0.90.2, 0.90.3, 0.90.4
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: noob
 Fix For: 0.90.1, 0.90.5


 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] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Affects Version/s: (was: 0.90.4)
   (was: 0.90.3)
   (was: 0.90.2)
Fix Version/s: (was: 0.90.1)

 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


 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] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Description: 
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}

  was:
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 is not 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}


 HConnectionImplementation closed-but-not-deleted, need a way to find the 
 state of connection
 

[jira] [Updated] (HBASE-4893) HConnectionImplementation closed-but-not-deleted, need a way to find the state of connection

[Mubarak Seyed (Updated) (JIRA)]

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

Mubarak Seyed updated HBASE-4893:
-

Fix Version/s: 0.90.1

 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, 0.90.2, 0.90.3, 0.90.4
 Environment: Linux 2.6, HBase-0.90.1
Reporter: Mubarak Seyed
  Labels: hbase-client
 Fix For: 0.90.1, 0.90.5


 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