[jira] [Updated] (HBASE-5798) NPE running hbck on 0.94 out of reportTablesInFlux
[
https://issues.apache.org/jira/browse/HBASE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-5798:
--
Attachment: HBASE-5798_trunk.patch
HBASE-5798_94.patch
Patch for trunk and 0.94
> NPE running hbck on 0.94 out of reportTablesInFlux
> --
>
> Key: HBASE-5798
> URL: https://issues.apache.org/jira/browse/HBASE-5798
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 0.94.0, 0.96.0
>Reporter: stack
>Assignee: Anoop Sam John
> Attachments: HBASE-5798_94.patch, HBASE-5798_trunk.patch
>
>
> Got this playing w/ hbck going against the 0.94RC:
> {code}
> 12/04/16 17:03:14 INFO util.HBaseFsck: getHTableDescriptors == tableNames =>
> []
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.HBaseFsck.reportTablesInFlux(HBaseFsck.java:553)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.onlineConsistencyRepair(HBaseFsck.java:344)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.onlineHbck(HBaseFsck.java:380)
> at org.apache.hadoop.hbase.util.HBaseFsck.main(HBaseFsck.java:3033)
> {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-5798) NPE running hbck on 0.94 out of reportTablesInFlux
[
https://issues.apache.org/jira/browse/HBASE-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-5798:
--
Component/s: hbck
Affects Version/s: 0.96.0
0.94.0
> NPE running hbck on 0.94 out of reportTablesInFlux
> --
>
> Key: HBASE-5798
> URL: https://issues.apache.org/jira/browse/HBASE-5798
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 0.94.0, 0.96.0
>Reporter: stack
>Assignee: Jonathan Hsieh
>
> Got this playing w/ hbck going against the 0.94RC:
> {code}
> 12/04/16 17:03:14 INFO util.HBaseFsck: getHTableDescriptors == tableNames =>
> []
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.HBaseFsck.reportTablesInFlux(HBaseFsck.java:553)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.onlineConsistencyRepair(HBaseFsck.java:344)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.onlineHbck(HBaseFsck.java:380)
> at org.apache.hadoop.hbase.util.HBaseFsck.main(HBaseFsck.java:3033)
> {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-5781) Zookeeper session got closed while trying to assign the region to RS using hbck -fix
[
https://issues.apache.org/jira/browse/HBASE-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-5781:
--
Affects Version/s: 0.94.0
> Zookeeper session got closed while trying to assign the region to RS using
> hbck -fix
>
>
> Key: HBASE-5781
> URL: https://issues.apache.org/jira/browse/HBASE-5781
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 0.94.0
>Reporter: Kristam Subba Swathi
>Assignee: Jonathan Hsieh
>
> After running the hbck in the cluster ,it is found that one region is not
> assigned
> So the hbck -fix is used to fix this
> But the assignment didnt happen since the zookeeper session is closed
> Please find the attached trace for more details
> -
> Trying to fix unassigned region...
> 12/04/03 11:02:57 INFO util.HBaseFsckRepair: Region still in transition,
> waiting for it to become assigned: {NAME =>
> 'ufdr,002300,179123498.00871fbd7583512e12c4eb38e900be8d.', STARTKEY =>
> '002300', ENDKEY => '002311', ENCODED => 00871fbd7583512e12c4eb38e900be8d,}
> 12/04/03 11:02:58 INFO client.HConnectionManager$HConnectionImplementation:
> Closed zookeeper sessionid=0x236738a263a
> 12/04/03 11:02:58 INFO zookeeper.ZooKeeper: Session: 0x236738a263a closed
> ERROR: Region { meta =>
> ufdr,010444,179123857.01594219211d0035b9586f98954462e1., hdfs =>
> hdfs://10.18.40.25:9000/hbase/ufdr/01594219211d0035b9586f98954462e1, deployed
> => } not deployed on any region server.
> Trying to fix unassigned region...
> 12/04/03 11:02:58 INFO zookeeper.ClientCnxn: EventThread shut down
> 12/04/03 11:02:58 WARN zookeeper.ZKUtil: hconnection-0x236738a263a Unable
> to set watcher on znode (/hbase)
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode
> = Session expired for /hbase
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1021)
> at
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:150)
> at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:263)
> at
> org.apache.hadoop.hbase.zookeeper.ZooKeeperNodeTracker.checkIfBaseNodeAvailable(ZooKeeperNodeTracker.java:208)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.checkIfBaseNodeAvailable(HConnectionManager.java:695)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getMaster(HConnectionManager.java:626)
> at org.apache.hadoop.hbase.client.HBaseAdmin.getMaster(HBaseAdmin.java:211)
> at org.apache.hadoop.hbase.client.HBaseAdmin.assign(HBaseAdmin.java:1325)
> at
> org.apache.hadoop.hbase.util.HBaseFsckRepair.forceOfflineInZK(HBaseFsckRepair.java:109)
> at
> org.apache.hadoop.hbase.util.HBaseFsckRepair.fixUnassigned(HBaseFsckRepair.java:92)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.tryAssignmentRepair(HBaseFsck.java:1235)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.checkRegionConsistency(HBaseFsck.java:1351)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.checkAndFixConsistency(HBaseFsck.java:1114)
> at
> org.apache.hadoop.hbase.util.HBaseFsck.onlineConsistencyRepair(HBaseFsck.java:356)
> at org.apache.hadoop.hbase.util.HBaseFsck.onlineHbck(HBaseFsck.java:375)
> at org.apache.hadoop.hbase.util.HBaseFsck.main(HBaseFsck.java:2894)
> 12/04/03 11:02:58 ERROR zookeeper.ZooKeeperWatcher:
> hconnection-0x236738a263a Received unexpected KeeperException,
> re-throwing exception
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode
> = Session expired for /hbase
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1021)
> at
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:150)
> at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:263)
> at
> org.apache.hadoop.hbase.zookeeper.ZooKeeperNodeTracker.checkIfBaseNodeAvailable(ZooKeeperNodeTracker.java:208)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.checkIfBaseNodeAvailable(HConnectionManager.java:695)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getMaster(HConnectionManager.java:626)
> at org.apache.hadoop.hbase.client.HBaseAdmin.getMaster(HBaseAdmin.java:211)
> at org.apache.hadoop.hbase.client.HBaseAdmin.assign(HBaseAdmin.java:1325)
> at
> org.apache.hadoop.hbase.util.HBaseFsckRepair.forceOfflineInZK(HBaseFsckRepair.java:109)
> at
> org.a
[jira] [Updated] (HBASE-5520) Support reseek() at RegionScanner
[ https://issues.apache.org/jira/browse/HBASE-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-5520: -- Description: reseek() is not supported currently at the RegionScanner level. We can support the same. This is created following the discussion under HBASE-2038 was: seek() reseek() is not supported currently at the RegionScanner level. We can support the same. This is created following the discussion under HBASE-2038 Assignee: ramkrishna.s.vasudevan Summary: Support reseek() at RegionScanner (was: Support seek() reseek() at RegionScanner) > Support reseek() at RegionScanner > - > > Key: HBASE-5520 > URL: https://issues.apache.org/jira/browse/HBASE-5520 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 0.92.0 >Reporter: Anoop Sam John >Assignee: ramkrishna.s.vasudevan > Attachments: HBASE-5520_1.patch > > > reseek() is not supported currently at the RegionScanner level. We can > support the same. > This is created following the discussion under HBASE-2038 -- 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-5520) Support seek() reseek() at RegionScanner
[ https://issues.apache.org/jira/browse/HBASE-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-5520: -- Description: seek() reseek() is not supported currently at the RegionScanner level. We can support the same. This is created following the discussion under HBASE-2038 was: seek() reseek() is not supported currently at the RegionScanner level. We can support the same. This is created following the discussion under HBASE_2038 > Support seek() reseek() at RegionScanner > > > Key: HBASE-5520 > URL: https://issues.apache.org/jira/browse/HBASE-5520 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 0.92.0 >Reporter: Anoop Sam John > > seek() reseek() is not supported currently at the RegionScanner level. We can > support the same. > This is created following the discussion under HBASE-2038 -- 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-5510) Change in LB.randomAssignment(List servers) API
[ https://issues.apache.org/jira/browse/HBASE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-5510: -- Attachment: HBase-5010_3.patch > Change in LB.randomAssignment(List servers) API > --- > > Key: HBASE-5510 > URL: https://issues.apache.org/jira/browse/HBASE-5510 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.92.0 >Reporter: Anoop Sam John >Assignee: ramkrishna.s.vasudevan > Fix For: 0.96.0 > > Attachments: HBase-5010_3.patch, HBase-5510.patch, HBase-5510_2.patch > > > In LB there is randomAssignment(List) API which will be > used by AM to assign > a region from a down RS. [This will be also used in other cases like call to > assign() API from client] > I feel it would be better to pass the HRegionInfo also into this method. > When the LB making a choice for a region > assignment, when one RS is down, it would be nice that the LB knows for > which region it is doing this server selection. > +Scenario+ > While one RS down, we wanted the regions to get moved to other RSs but a set > of regions stay together. We are having custom load balancer but with the > current way of LB interface this is not possible. Another way is I can allow > a random assignment of the regions at the RS down time. Later with a cluster > balance I can balance the regions as I need. But this might make regions > assign 1st to one RS and then again move to another. Also for some time > period my business use case can not get satisfied. > Also I have seen some issue in JIRA which speaks about making sure that Root > and META regions always sit in some specific RSs. With the current LB API > this wont be possible in future. -- 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-5510) Change in LB.randomAssignment(List servers) API
[ https://issues.apache.org/jira/browse/HBASE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-5510: -- Attachment: HBase-5510_2.patch > Change in LB.randomAssignment(List servers) API > --- > > Key: HBASE-5510 > URL: https://issues.apache.org/jira/browse/HBASE-5510 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.92.0 >Reporter: Anoop Sam John >Assignee: ramkrishna.s.vasudevan > Attachments: HBase-5510.patch, HBase-5510_2.patch > > > In LB there is randomAssignment(List) API which will be > used by AM to assign > a region from a down RS. [This will be also used in other cases like call to > assign() API from client] > I feel it would be better to pass the HRegionInfo also into this method. > When the LB making a choice for a region > assignment, when one RS is down, it would be nice that the LB knows for > which region it is doing this server selection. > +Scenario+ > While one RS down, we wanted the regions to get moved to other RSs but a set > of regions stay together. We are having custom load balancer but with the > current way of LB interface this is not possible. Another way is I can allow > a random assignment of the regions at the RS down time. Later with a cluster > balance I can balance the regions as I need. But this might make regions > assign 1st to one RS and then again move to another. Also for some time > period my business use case can not get satisfied. > Also I have seen some issue in JIRA which speaks about making sure that Root > and META regions always sit in some specific RSs. With the current LB API > this wont be possible in future. -- 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-5510) Change in LB.randomAssignment(List servers) API
[ https://issues.apache.org/jira/browse/HBASE-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-5510: -- Attachment: HBase-5510.patch > Change in LB.randomAssignment(List servers) API > --- > > Key: HBASE-5510 > URL: https://issues.apache.org/jira/browse/HBASE-5510 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.92.0 >Reporter: Anoop Sam John >Assignee: ramkrishna.s.vasudevan > Attachments: HBase-5510.patch > > > In LB there is randomAssignment(List) API which will be > used by AM to assign > a region from a down RS. [This will be also used in other cases like call to > assign() API from client] > I feel it would be better to pass the HRegionInfo also into this method. > When the LB making a choice for a region > assignment, when one RS is down, it would be nice that the LB knows for > which region it is doing this server selection. > +Scenario+ > While one RS down, we wanted the regions to get moved to other RSs but a set > of regions stay together. We are having custom load balancer but with the > current way of LB interface this is not possible. Another way is I can allow > a random assignment of the regions at the RS down time. Later with a cluster > balance I can balance the regions as I need. But this might make regions > assign 1st to one RS and then again move to another. Also for some time > period my business use case can not get satisfied. > Also I have seen some issue in JIRA which speaks about making sure that Root > and META regions always sit in some specific RSs. With the current LB API > this wont be possible in future. -- 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
