[jira] [Commented] (HBASE-5347) GC free memory management in Level-1 Block Cache
[ https://issues.apache.org/jira/browse/HBASE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211290#comment-13211290 ] Zhihong Yu commented on HBASE-5347: --- In filterRow(), we should deref the KeyValue which is removed from the list of KeyValues parameter. In 0.89-fb branch, I found DependentColumnFilter where the above change should be added. > GC free memory management in Level-1 Block Cache > > > Key: HBASE-5347 > URL: https://issues.apache.org/jira/browse/HBASE-5347 > Project: HBase > Issue Type: Improvement >Reporter: Prakash Khemani >Assignee: Prakash Khemani > Attachments: D1635.5.patch > > > On eviction of a block from the block-cache, instead of waiting for the > garbage collecter to reuse its memory, reuse the block right away. > This will require us to keep reference counts on the HFile blocks. Once we > have the reference counts in place we can do our own simple > blocks-out-of-slab allocation for the block-cache. > This will help us with > * reducing gc pressure, especially in the old generation > * making it possible to have non-java-heap memory backing the HFile blocks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5399) Cut the link between the client and the zookeeper ensemble
[ https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211313#comment-13211313 ] nkeywal commented on HBASE-5399: bq. Are we getting retrieveClusterId on startup? Can we not do that? Can we do that when someone asks for it? Or is it happening after we've set up the zk connection anyways? We're doing it when we create the connection, so we're connection for ZK just for this today. However, I think that we should also connect to ZK to get the master address (this would allow to start a client without specifying the master address: today it must be in ZK but also in client configuration). Wet would still connect to ZK at starting time, so, but for two reasons instead of only one. On another hand, There's a comment from Gary on the bug review tracker (https://review.cloudera.org//r/1669/) for HBASE-3677: ??Yes, no real need for a tracker. Andy and I had discussed that previously. ZK is just used to broadcast the ID to clients and servers without the need for HBase RPC (which for token authentication requires selection of the right token, but we don't know the token without the ID...). I'll post an update that just reads the ID from ZK without using a tracker.?? So It seems that we could safely: - remove the clusterIdWatcher class - replace the conf parameter "hbase.cluster.id" by a simple getter on Connection. That would allow to get the id only when asked, with a lazy initialization, hence connecting later to ZK. I don't mind doing this, but it's better to do it in another jira (this one's too big already). > Cut the link between the client and the zookeeper ensemble > -- > > Key: HBASE-5399 > URL: https://issues.apache.org/jira/browse/HBASE-5399 > Project: HBase > Issue Type: Improvement > Components: client >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch > > > The link is often considered as an issue, for various reasons. One of them > being that there is a limit on the number of connection that ZK can manage. > Stack was suggesting as well to remove the link to master from HConnection. > There are choices to be made considering the existing API (that we don't want > to break). > The first patches I will submit on hadoop-qa should not be committed: they > are here to show the progress on the direction taken. > ZooKeeper is used for: > - public getter, to let the client do whatever he wants, and close ZooKeeper > when closing the connection => we have to deprecate this but keep it. > - read get master address to create a master => now done with a temporary > zookeeper connection > - read root location => now done with a temporary zookeeper connection, but > questionable. Used in public function "locateRegion". To be reworked. > - read cluster id => now done once with a temporary zookeeper connection. > - check if base done is available => now done once with a zookeeper > connection given as a parameter > - isTableDisabled/isTableAvailable => public functions, now done with a > temporary zookeeper connection. > - Called internally from HBaseAdmin and HTable > - getCurrentNrHRS(): public function to get the number of region servers and > create a pool of thread => now done with a temporary zookeeper connection > - > Master is used for: > - getMaster public getter, as for ZooKeeper => we have to deprecate this but > keep it. > - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin > - getHTableDescriptor*: public functions offering access to the master. => > we could make them using a temporary master connection as well. > Main points are: > - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a > strongly coupled architecture ;-). This can be changed, but requires a lot of > modifications in these classes (likely adding a class in the middle of the > hierarchy, something like that). Anyway, non connected client will always be > really slower, because it's a tcp connection, and establishing a tcp > connection is slow. > - having a link between ZK and all the client seems to make sense for some > Use Cases. However, it won't scale if a TCP connection is required for every > client > - if we move the table descriptor part away from the client, we need to find > a new place for it. > - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we > can put a timeout on the connection. That would make the whole system less > deterministic however. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://is
[jira] [Commented] (HBASE-5200) AM.ProcessRegionInTransition() and AM.handleRegion() race thus leaving the region assignment inconsistent
[
https://issues.apache.org/jira/browse/HBASE-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211390#comment-13211390
]
ramkrishna.s.vasudevan commented on HBASE-5200:
---
Thanks for the commit Stack. I was just thought of committing if it had not
been.
> AM.ProcessRegionInTransition() and AM.handleRegion() race thus leaving the
> region assignment inconsistent
> -
>
> Key: HBASE-5200
> URL: https://issues.apache.org/jira/browse/HBASE-5200
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.90.5
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 0.94.0, 0.92.1
>
> Attachments: 5200-test.txt, 5200-v2.txt, 5200-v3.txt,
> 5200-v4-092.txt, 5200-v4.txt, 5200-v4no-prefix.txt, HBASE-5200.patch,
> HBASE-5200_1.patch, HBASE-5200_trunk_latest_with_test_2.patch,
> TEST-org.apache.hadoop.hbase.master.TestRestartCluster.xml,
> hbase-5200_90_latest.patch, hbase-5200_90_latest_new.patch
>
>
> This is the scenario
> Consider a case where the balancer is going on thus trying to close regions
> in a RS.
> Before we could close a master switch happens.
> On Master switch the set of nodes that are in RIT is collected and we first
> get Data and start watching the node
> After that the node data is added into RIT.
> Now by this time (before adding to RIT) if the RS to which close was called
> does a transition in AM.handleRegion() we miss the handling saying RIT state
> was null.
> {code}
> 2012-01-13 10:50:46,358 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> a66d281d231dfcaea97c270698b26b6f from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,358 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> c12e53bfd48ddc5eec507d66821c4d23 from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,358 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> 59ae13de8c1eb325a0dd51f4902d2052 from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> f45bc9614d7575f35244849af85aa078 from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> cc3ecd7054fe6cd4a1159ed92fd62641 from server
> HOST-192-168-47-204,20020,1326342744518 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> 3af40478a17fee96b4a192b22c90d5a2 from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> e6096a8466e730463e10d3d61f809b92 from server
> HOST-192-168-47-204,20020,1326342744518 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> 4806781a1a23066f7baed22b4d237e24 from server
> HOST-192-168-47-204,20020,1326342744518 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> 2012-01-13 10:50:46,359 WARN
> org.apache.hadoop.hbase.master.AssignmentManager: Received CLOSED for region
> d69e104131accaefe21dcc01fddc7629 from server
> HOST-192-168-47-205,20020,1326363111288 but region was in the state null and
> not in expected PENDING_CLOSE or CLOSING states
> {code}
> In branch the CLOSING node is created by RS thus leading to more
> inconsistency.
--
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-5399) Cut the link between the client and the zookeeper ensemble
[ https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-5399: --- Attachment: 5399_inprogress.v9.patch > Cut the link between the client and the zookeeper ensemble > -- > > Key: HBASE-5399 > URL: https://issues.apache.org/jira/browse/HBASE-5399 > Project: HBase > Issue Type: Improvement > Components: client >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch, > 5399_inprogress.v9.patch > > > The link is often considered as an issue, for various reasons. One of them > being that there is a limit on the number of connection that ZK can manage. > Stack was suggesting as well to remove the link to master from HConnection. > There are choices to be made considering the existing API (that we don't want > to break). > The first patches I will submit on hadoop-qa should not be committed: they > are here to show the progress on the direction taken. > ZooKeeper is used for: > - public getter, to let the client do whatever he wants, and close ZooKeeper > when closing the connection => we have to deprecate this but keep it. > - read get master address to create a master => now done with a temporary > zookeeper connection > - read root location => now done with a temporary zookeeper connection, but > questionable. Used in public function "locateRegion". To be reworked. > - read cluster id => now done once with a temporary zookeeper connection. > - check if base done is available => now done once with a zookeeper > connection given as a parameter > - isTableDisabled/isTableAvailable => public functions, now done with a > temporary zookeeper connection. > - Called internally from HBaseAdmin and HTable > - getCurrentNrHRS(): public function to get the number of region servers and > create a pool of thread => now done with a temporary zookeeper connection > - > Master is used for: > - getMaster public getter, as for ZooKeeper => we have to deprecate this but > keep it. > - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin > - getHTableDescriptor*: public functions offering access to the master. => > we could make them using a temporary master connection as well. > Main points are: > - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a > strongly coupled architecture ;-). This can be changed, but requires a lot of > modifications in these classes (likely adding a class in the middle of the > hierarchy, something like that). Anyway, non connected client will always be > really slower, because it's a tcp connection, and establishing a tcp > connection is slow. > - having a link between ZK and all the client seems to make sense for some > Use Cases. However, it won't scale if a TCP connection is required for every > client > - if we move the table descriptor part away from the client, we need to find > a new place for it. > - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we > can put a timeout on the connection. That would make the whole system less > deterministic however. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5399) Cut the link between the client and the zookeeper ensemble
[
https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211422#comment-13211422
]
nkeywal commented on HBASE-5399:
In v9 I added some comments and fixed some issues.
bq. I'd say lets not check master is there till we need it. Seems like a PITA
going ahead and checking master on construction. This changes the behavior but
I think its one thats ok to change.
Agreed, removed in v9.
bq. You are doing your own Callables. You've seen the Callables that go on in
HTable. Any reason you avoid them? I suppose this is different in that you want
to let go of the shared master. Looks fine.
I could also add the master management in the HTable callables. I would still
need the one I wrote for HBaseAdmin, but it could be useful to be able to use
master from the HTable callables?
I still need to work on the unit tests, some large tests are failing today:
{noformat}
Failed tests: testBackgroundEvictionThread[1](org.apache.hadoop.hbase.io.hfile
.TestLruBlockCache)
testShutdownFixupWhenDaughterHasSplit(org.apache.hadoop.hbase.regionserver.Tes
tSplitTransactionOnCluster): expected:<1> but was:<0>
queueFailover(org.apache.hadoop.hbase.replication.TestReplication): Waited too
much time for queueFailover replication
testMergeTool(org.apache.hadoop.hbase.util.TestMergeTool): 'merging regions 0
and 1' failed with errCode -1
Tests in error:
test3686a(org.apache.hadoop.hbase.client.TestScannerTimeout): 64142ms passed s
ince the last invocation, timeout is currently set to 1
{noformat}
For some of them it could be random and unrelated, but I am sure there are some
real issues for of them.
I am on vacations next week; so I will come back to it the week after...
> Cut the link between the client and the zookeeper ensemble
> --
>
> Key: HBASE-5399
> URL: https://issues.apache.org/jira/browse/HBASE-5399
> Project: HBase
> Issue Type: Improvement
> Components: client
>Affects Versions: 0.94.0
> Environment: all
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Minor
> Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch,
> 5399_inprogress.v9.patch
>
>
> The link is often considered as an issue, for various reasons. One of them
> being that there is a limit on the number of connection that ZK can manage.
> Stack was suggesting as well to remove the link to master from HConnection.
> There are choices to be made considering the existing API (that we don't want
> to break).
> The first patches I will submit on hadoop-qa should not be committed: they
> are here to show the progress on the direction taken.
> ZooKeeper is used for:
> - public getter, to let the client do whatever he wants, and close ZooKeeper
> when closing the connection => we have to deprecate this but keep it.
> - read get master address to create a master => now done with a temporary
> zookeeper connection
> - read root location => now done with a temporary zookeeper connection, but
> questionable. Used in public function "locateRegion". To be reworked.
> - read cluster id => now done once with a temporary zookeeper connection.
> - check if base done is available => now done once with a zookeeper
> connection given as a parameter
> - isTableDisabled/isTableAvailable => public functions, now done with a
> temporary zookeeper connection.
> - Called internally from HBaseAdmin and HTable
> - getCurrentNrHRS(): public function to get the number of region servers and
> create a pool of thread => now done with a temporary zookeeper connection
> -
> Master is used for:
> - getMaster public getter, as for ZooKeeper => we have to deprecate this but
> keep it.
> - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin
> - getHTableDescriptor*: public functions offering access to the master. =>
> we could make them using a temporary master connection as well.
> Main points are:
> - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a
> strongly coupled architecture ;-). This can be changed, but requires a lot of
> modifications in these classes (likely adding a class in the middle of the
> hierarchy, something like that). Anyway, non connected client will always be
> really slower, because it's a tcp connection, and establishing a tcp
> connection is slow.
> - having a link between ZK and all the client seems to make sense for some
> Use Cases. However, it won't scale if a TCP connection is required for every
> client
> - if we move the table descriptor part away from the client, we need to find
> a new place for it.
> - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we
> can put a timeout on the connection. That would make the whole system less
>
[jira] [Commented] (HBASE-5399) Cut the link between the client and the zookeeper ensemble
[ https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211435#comment-13211435 ] nkeywal commented on HBASE-5399: Moreover, v9 patch work on trunk as of today. > Cut the link between the client and the zookeeper ensemble > -- > > Key: HBASE-5399 > URL: https://issues.apache.org/jira/browse/HBASE-5399 > Project: HBase > Issue Type: Improvement > Components: client >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch, > 5399_inprogress.v9.patch > > > The link is often considered as an issue, for various reasons. One of them > being that there is a limit on the number of connection that ZK can manage. > Stack was suggesting as well to remove the link to master from HConnection. > There are choices to be made considering the existing API (that we don't want > to break). > The first patches I will submit on hadoop-qa should not be committed: they > are here to show the progress on the direction taken. > ZooKeeper is used for: > - public getter, to let the client do whatever he wants, and close ZooKeeper > when closing the connection => we have to deprecate this but keep it. > - read get master address to create a master => now done with a temporary > zookeeper connection > - read root location => now done with a temporary zookeeper connection, but > questionable. Used in public function "locateRegion". To be reworked. > - read cluster id => now done once with a temporary zookeeper connection. > - check if base done is available => now done once with a zookeeper > connection given as a parameter > - isTableDisabled/isTableAvailable => public functions, now done with a > temporary zookeeper connection. > - Called internally from HBaseAdmin and HTable > - getCurrentNrHRS(): public function to get the number of region servers and > create a pool of thread => now done with a temporary zookeeper connection > - > Master is used for: > - getMaster public getter, as for ZooKeeper => we have to deprecate this but > keep it. > - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin > - getHTableDescriptor*: public functions offering access to the master. => > we could make them using a temporary master connection as well. > Main points are: > - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a > strongly coupled architecture ;-). This can be changed, but requires a lot of > modifications in these classes (likely adding a class in the middle of the > hierarchy, something like that). Anyway, non connected client will always be > really slower, because it's a tcp connection, and establishing a tcp > connection is slow. > - having a link between ZK and all the client seems to make sense for some > Use Cases. However, it won't scale if a TCP connection is required for every > client > - if we move the table descriptor part away from the client, we need to find > a new place for it. > - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we > can put a timeout on the connection. That would make the whole system less > deterministic however. -- 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] [Created] (HBASE-5435) TestForceCacheImportantBlocks fails with OutOfMemoryError
TestForceCacheImportantBlocks fails with OutOfMemoryError
-
Key: HBASE-5435
URL: https://issues.apache.org/jira/browse/HBASE-5435
Project: HBase
Issue Type: Test
Reporter: Zhihong Yu
Fix For: 0.94.0
Here is related stack trace (see
https://builds.apache.org/job/HBase-TRUNK/2665/testReport/org.apache.hadoop.hbase.io.hfile/TestForceCacheImportantBlocks/testCacheBlocks_1_/):
{code}
Caused by: java.lang.OutOfMemoryError
at java.util.zip.Deflater.init(Native Method)
at java.util.zip.Deflater.(Deflater.java:124)
at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:46)
at java.util.zip.GZIPOutputStream.(GZIPOutputStream.java:58)
at
org.apache.hadoop.hbase.io.hfile.ReusableStreamGzipCodec$ReusableGzipOutputStream$ResetableGZIPOutputStream.(ReusableStreamGzipCodec.java:79)
at
org.apache.hadoop.hbase.io.hfile.ReusableStreamGzipCodec$ReusableGzipOutputStream.(ReusableStreamGzipCodec.java:90)
at
org.apache.hadoop.hbase.io.hfile.ReusableStreamGzipCodec.createOutputStream(ReusableStreamGzipCodec.java:130)
at
org.apache.hadoop.io.compress.GzipCodec.createOutputStream(GzipCodec.java:101)
at
org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.createPlainCompressionStream(Compression.java:239)
at
org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.createCompressionStream(Compression.java:223)
at
org.apache.hadoop.hbase.io.hfile.HFileWriterV1.getCompressingStream(HFileWriterV1.java:270)
at
org.apache.hadoop.hbase.io.hfile.HFileWriterV1.close(HFileWriterV1.java:416)
at
org.apache.hadoop.hbase.regionserver.StoreFile$Writer.close(StoreFile.java:1115)
at
org.apache.hadoop.hbase.regionserver.Store.internalFlushCache(Store.java:706)
at org.apache.hadoop.hbase.regionserver.Store.flushCache(Store.java:633)
at org.apache.hadoop.hbase.regionserver.Store.access$400(Store.java:106)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5347) GC free memory management in Level-1 Block Cache
[ https://issues.apache.org/jira/browse/HBASE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211598#comment-13211598 ] Prakash Khemani commented on HBASE-5347: Thanks for the reviews. I will make another pass pretty soon. Todd, What you have suggested will not help when a piece of code wants to bump up the reference count because it is keeping the reference to the object in some state variable. (for example the store scanner does it after a flush). But your suggestion will work in those cases where a piece of code forgets to decrement the reference count. The current patch also has similar characteristics. It cannot automatically bump up the reference count. But if it forgets to do dereference and decrement the ref count then it relies on WeakReferences and garbage collection to do the same. On 2/19/12 12:56 AM, "Zhihong Yu (Commented) (JIRA)" > GC free memory management in Level-1 Block Cache > > > Key: HBASE-5347 > URL: https://issues.apache.org/jira/browse/HBASE-5347 > Project: HBase > Issue Type: Improvement >Reporter: Prakash Khemani >Assignee: Prakash Khemani > Attachments: D1635.5.patch > > > On eviction of a block from the block-cache, instead of waiting for the > garbage collecter to reuse its memory, reuse the block right away. > This will require us to keep reference counts on the HFile blocks. Once we > have the reference counts in place we can do our own simple > blocks-out-of-slab allocation for the block-cache. > This will help us with > * reducing gc pressure, especially in the old generation > * making it possible to have non-java-heap memory backing the HFile blocks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5347) GC free memory management in Level-1 Block Cache
[ https://issues.apache.org/jira/browse/HBASE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211610#comment-13211610 ] Lars Hofhansl commented on HBASE-5347: -- @Ted: That might be right thing to do in filterRow(), but I am slowly getting this feeling that this will put a lot of onus to account for this on various HBase parts (such as filters). > GC free memory management in Level-1 Block Cache > > > Key: HBASE-5347 > URL: https://issues.apache.org/jira/browse/HBASE-5347 > Project: HBase > Issue Type: Improvement >Reporter: Prakash Khemani >Assignee: Prakash Khemani > Attachments: D1635.5.patch > > > On eviction of a block from the block-cache, instead of waiting for the > garbage collecter to reuse its memory, reuse the block right away. > This will require us to keep reference counts on the HFile blocks. Once we > have the reference counts in place we can do our own simple > blocks-out-of-slab allocation for the block-cache. > This will help us with > * reducing gc pressure, especially in the old generation > * making it possible to have non-java-heap memory backing the HFile blocks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5399) Cut the link between the client and the zookeeper ensemble
[ https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211612#comment-13211612 ] Lars Hofhansl commented on HBASE-5399: -- @Nicolas: Could you upload the patch to RB? That would make it easier to review. I'm loving all changes discussed here so far :) > Cut the link between the client and the zookeeper ensemble > -- > > Key: HBASE-5399 > URL: https://issues.apache.org/jira/browse/HBASE-5399 > Project: HBase > Issue Type: Improvement > Components: client >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch, > 5399_inprogress.v9.patch > > > The link is often considered as an issue, for various reasons. One of them > being that there is a limit on the number of connection that ZK can manage. > Stack was suggesting as well to remove the link to master from HConnection. > There are choices to be made considering the existing API (that we don't want > to break). > The first patches I will submit on hadoop-qa should not be committed: they > are here to show the progress on the direction taken. > ZooKeeper is used for: > - public getter, to let the client do whatever he wants, and close ZooKeeper > when closing the connection => we have to deprecate this but keep it. > - read get master address to create a master => now done with a temporary > zookeeper connection > - read root location => now done with a temporary zookeeper connection, but > questionable. Used in public function "locateRegion". To be reworked. > - read cluster id => now done once with a temporary zookeeper connection. > - check if base done is available => now done once with a zookeeper > connection given as a parameter > - isTableDisabled/isTableAvailable => public functions, now done with a > temporary zookeeper connection. > - Called internally from HBaseAdmin and HTable > - getCurrentNrHRS(): public function to get the number of region servers and > create a pool of thread => now done with a temporary zookeeper connection > - > Master is used for: > - getMaster public getter, as for ZooKeeper => we have to deprecate this but > keep it. > - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin > - getHTableDescriptor*: public functions offering access to the master. => > we could make them using a temporary master connection as well. > Main points are: > - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a > strongly coupled architecture ;-). This can be changed, but requires a lot of > modifications in these classes (likely adding a class in the middle of the > hierarchy, something like that). Anyway, non connected client will always be > really slower, because it's a tcp connection, and establishing a tcp > connection is slow. > - having a link between ZK and all the client seems to make sense for some > Use Cases. However, it won't scale if a TCP connection is required for every > client > - if we move the table descriptor part away from the client, we need to find > a new place for it. > - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we > can put a timeout on the connection. That would make the whole system less > deterministic however. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3149) Make flush decisions per column family
[ https://issues.apache.org/jira/browse/HBASE-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211614#comment-13211614 ] Lars Hofhansl commented on HBASE-3149: -- @Nicolas: Interesting bit about hstore.compaction.min.size. I'm curious, is 4MB something that works specifically for your setup, or would you generally recommend it setting it that low? It probably has to do with whether compression is enabled, how many CFs and relative sizes, etc. Maybe instead of defaulting it to flushsize, we could default it to flushsize/2 or flushsize/4...? > Make flush decisions per column family > -- > > Key: HBASE-3149 > URL: https://issues.apache.org/jira/browse/HBASE-3149 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Karthik Ranganathan >Assignee: Nicolas Spiegelberg > > Today, the flush decision is made using the aggregate size of all column > families. When large and small column families co-exist, this causes many > small flushes of the smaller CF. We need to make per-CF flush decisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4365) Add a decent heuristic for region size
[ https://issues.apache.org/jira/browse/HBASE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211619#comment-13211619 ] Lars Hofhansl commented on HBASE-4365: -- Wouldn't we potentially do a lot of splitting when there are many regionservers? (Maybe I am not grokking this fully) If we take the square of the of the number of regions, and say we have 10gb regions and flush size of 128mb, we'd read the 10gb after at 9 regions of the table on the same regionserver. We were planning a region size of 5gb and flush size of 256mb, that would still be 5 regions. (10gb/128mb ~ 78, 5gb/256mb ~ 19) > Add a decent heuristic for region size > -- > > Key: HBASE-4365 > URL: https://issues.apache.org/jira/browse/HBASE-4365 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.0, 0.92.1 >Reporter: Todd Lipcon >Priority: Critical > Labels: usability > Attachments: 4365.txt > > > A few of us were brainstorming this morning about what the default region > size should be. There were a few general points made: > - in some ways it's better to be too-large than too-small, since you can > always split a table further, but you can't merge regions currently > - with HFile v2 and multithreaded compactions there are fewer reasons to > avoid very-large regions (10GB+) > - for small tables you may want a small region size just so you can > distribute load better across a cluster > - for big tables, multi-GB is probably best -- 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] [Issue Comment Edited] (HBASE-4365) Add a decent heuristic for region size
[ https://issues.apache.org/jira/browse/HBASE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211619#comment-13211619 ] Lars Hofhansl edited comment on HBASE-4365 at 2/20/12 12:39 AM: Wouldn't we potentially do a lot of splitting when there are many regionservers? (Maybe I am not grokking this fully) If we take the square of the of the number of regions, and say we have 10gb regions and flush size of 128mb, we'd reach the 10gb after at 9 regions of the table on the same regionserver. We were planning a region size of 5gb and flush size of 256mb, that would still be 5 regions. (10gb/128mb ~ 78, 5gb/256mb ~ 19) was (Author: lhofhansl): Wouldn't we potentially do a lot of splitting when there are many regionservers? (Maybe I am not grokking this fully) If we take the square of the of the number of regions, and say we have 10gb regions and flush size of 128mb, we'd read the 10gb after at 9 regions of the table on the same regionserver. We were planning a region size of 5gb and flush size of 256mb, that would still be 5 regions. (10gb/128mb ~ 78, 5gb/256mb ~ 19) > Add a decent heuristic for region size > -- > > Key: HBASE-4365 > URL: https://issues.apache.org/jira/browse/HBASE-4365 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.0, 0.92.1 >Reporter: Todd Lipcon >Priority: Critical > Labels: usability > Attachments: 4365.txt > > > A few of us were brainstorming this morning about what the default region > size should be. There were a few general points made: > - in some ways it's better to be too-large than too-small, since you can > always split a table further, but you can't merge regions currently > - with HFile v2 and multithreaded compactions there are fewer reasons to > avoid very-large regions (10GB+) > - for small tables you may want a small region size just so you can > distribute load better across a cluster > - for big tables, multi-GB is probably best -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4365) Add a decent heuristic for region size
[ https://issues.apache.org/jira/browse/HBASE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211620#comment-13211620 ] Lars Hofhansl commented on HBASE-4365: -- Never use a calculator... 10gb/128mb = 80, 5bgb/256mb = 20. > Add a decent heuristic for region size > -- > > Key: HBASE-4365 > URL: https://issues.apache.org/jira/browse/HBASE-4365 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.0, 0.92.1 >Reporter: Todd Lipcon >Priority: Critical > Labels: usability > Attachments: 4365.txt > > > A few of us were brainstorming this morning about what the default region > size should be. There were a few general points made: > - in some ways it's better to be too-large than too-small, since you can > always split a table further, but you can't merge regions currently > - with HFile v2 and multithreaded compactions there are fewer reasons to > avoid very-large regions (10GB+) > - for small tables you may want a small region size just so you can > distribute load better across a cluster > - for big tables, multi-GB is probably best -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5332) Deterministic Compaction Jitter
[ https://issues.apache.org/jira/browse/HBASE-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211641#comment-13211641 ] Phabricator commented on HBASE-5332: nspiegelberg has commented on the revision "[jira] [HBASE-5332] Deterministic Compaction Jitter". INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/regionserver/Store.java:1067 I can null check. note that this variable is not null-checked in a lot of places in Store.java. Wish there was a way to guarantee non-null src/main/java/org/apache/hadoop/hbase/regionserver/Store.java:1065 I was worried about a case where this check happened while a major compaction was finishing up (see Store.completeCompaction). Besides per-file compactions, the HRegionServer.CompactionChecker thread is another area where this race can occur. Maybe this isn't a practical problem since we don't cache this calculation anymore & the major compaction interval should normally be very large so a race condition won't trigger a major compaction. src/main/java/org/apache/hadoop/hbase/regionserver/Store.java:1068 Thinking about it more, the pathname alone should suffice since it's a 'crypographically strong' random UUID REVISION DETAIL https://reviews.facebook.net/D1785 > Deterministic Compaction Jitter > --- > > Key: HBASE-5332 > URL: https://issues.apache.org/jira/browse/HBASE-5332 > Project: HBase > Issue Type: Improvement >Reporter: Nicolas Spiegelberg >Assignee: Nicolas Spiegelberg >Priority: Minor > Attachments: D1785.1.patch, D1785.2.patch > > > Currently, we add jitter to a compaction using "delay + jitter*(1 - > 2*Math.random())". Since this is non-deterministic, we can get major > compaction storms on server restart as half the Stores that were set to > "delay + jitter" will now be set to "delay - jitter". We need a more > deterministic way to jitter major compactions so this information can persist > across server restarts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5332) Deterministic Compaction Jitter
[ https://issues.apache.org/jira/browse/HBASE-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211642#comment-13211642 ] Nicolas Spiegelberg commented on HBASE-5332: @Lars: note that the operation you describe is operating on a double and converting to a long at the end, so there is no loss of granularity. Also note that the other proposed changes would 2x and 3x the jitter from the user-configured percentage value. > Deterministic Compaction Jitter > --- > > Key: HBASE-5332 > URL: https://issues.apache.org/jira/browse/HBASE-5332 > Project: HBase > Issue Type: Improvement >Reporter: Nicolas Spiegelberg >Assignee: Nicolas Spiegelberg >Priority: Minor > Attachments: D1785.1.patch, D1785.2.patch > > > Currently, we add jitter to a compaction using "delay + jitter*(1 - > 2*Math.random())". Since this is non-deterministic, we can get major > compaction storms on server restart as half the Stores that were set to > "delay + jitter" will now be set to "delay - jitter". We need a more > deterministic way to jitter major compactions so this information can persist > across server restarts. -- 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-5332) Deterministic Compaction Jitter
[ https://issues.apache.org/jira/browse/HBASE-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phabricator updated HBASE-5332: --- Attachment: D1785.3.patch nspiegelberg updated the revision "[jira] [HBASE-5332] Deterministic Compaction Jitter". Reviewers: JIRA, Kannan, aaiyer, stack Addressed Kannan's peer review. Raised compaction delay because of false positives when the jitter brought it to 3 sec. REVISION DETAIL https://reviews.facebook.net/D1785 AFFECTED FILES src/main/java/org/apache/hadoop/hbase/regionserver/Store.java src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactSelection.java src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java > Deterministic Compaction Jitter > --- > > Key: HBASE-5332 > URL: https://issues.apache.org/jira/browse/HBASE-5332 > Project: HBase > Issue Type: Improvement >Reporter: Nicolas Spiegelberg >Assignee: Nicolas Spiegelberg >Priority: Minor > Attachments: D1785.1.patch, D1785.2.patch, D1785.3.patch > > > Currently, we add jitter to a compaction using "delay + jitter*(1 - > 2*Math.random())". Since this is non-deterministic, we can get major > compaction storms on server restart as half the Stores that were set to > "delay + jitter" will now be set to "delay - jitter". We need a more > deterministic way to jitter major compactions so this information can persist > across server restarts. -- 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-5424) HTable meet NPE when call getRegionInfo()
[ https://issues.apache.org/jira/browse/HBASE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiyuan.dai updated HBASE-5424: --- Attachment: HBase-5424_1.patch > HTable meet NPE when call getRegionInfo() > - > > Key: HBASE-5424 > URL: https://issues.apache.org/jira/browse/HBASE-5424 > Project: HBase > Issue Type: Bug >Affects Versions: 0.90.1, 0.90.5 >Reporter: junhua yang > Attachments: HBASE-5424.patch, HBase-5424_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We meet NPE when call getRegionInfo() in testing environment. > Exception in thread "main" java.lang.NullPointerException > at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:75) > at org.apache.hadoop.hbase.util.Writables.getHRegionInfo(Writables.java:119) > at org.apache.hadoop.hbase.client.HTable$2.processRow(HTable.java:395) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:190) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:73) > at org.apache.hadoop.hbase.client.HTable.getRegionsInfo(HTable.java:418) > This NPE also make the table.jsp can't show the region information of this > table. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5424) HTable meet NPE when call getRegionInfo()
[ https://issues.apache.org/jira/browse/HBASE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211649#comment-13211649 ] Hadoop QA commented on HBASE-5424: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12515208/HBase-5424_1.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/991//console This message is automatically generated. > HTable meet NPE when call getRegionInfo() > - > > Key: HBASE-5424 > URL: https://issues.apache.org/jira/browse/HBASE-5424 > Project: HBase > Issue Type: Bug >Affects Versions: 0.90.1, 0.90.5 >Reporter: junhua yang > Attachments: HBASE-5424.patch, HBase-5424_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We meet NPE when call getRegionInfo() in testing environment. > Exception in thread "main" java.lang.NullPointerException > at org.apache.hadoop.hbase.util.Writables.getWritable(Writables.java:75) > at org.apache.hadoop.hbase.util.Writables.getHRegionInfo(Writables.java:119) > at org.apache.hadoop.hbase.client.HTable$2.processRow(HTable.java:395) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:190) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95) > at org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:73) > at org.apache.hadoop.hbase.client.HTable.getRegionsInfo(HTable.java:418) > This NPE also make the table.jsp can't show the region information of this > table. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5431) Improve delete marker handling in Import M/R jobs
[ https://issues.apache.org/jira/browse/HBASE-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211681#comment-13211681 ] Hudson commented on HBASE-5431: --- Integrated in HBase-TRUNK-security #117 (See [https://builds.apache.org/job/HBase-TRUNK-security/117/]) HBASE-5431 Improve delete marker handling in Import M/R jobs (Revision 1290955) Result = FAILURE larsh : Files : * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/Delete.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java > Improve delete marker handling in Import M/R jobs > - > > Key: HBASE-5431 > URL: https://issues.apache.org/jira/browse/HBASE-5431 > Project: HBase > Issue Type: Sub-task > Components: mapreduce >Affects Versions: 0.94.0 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Minor > Fix For: 0.94.0 > > Attachments: 5431.txt > > > Import currently create a new Delete object for each delete KV found in a > result object. > This can be improved with the new Delete API that allows adding a delete KV > to a Delete object. -- 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-5075) regionserver crashed and failover
[ https://issues.apache.org/jira/browse/HBASE-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiyuan.dai updated HBASE-5075: --- Attachment: (was: 5075.patch) > regionserver crashed and failover > - > > Key: HBASE-5075 > URL: https://issues.apache.org/jira/browse/HBASE-5075 > Project: HBase > Issue Type: Improvement > Components: monitoring, regionserver, replication, zookeeper >Affects Versions: 0.92.1 >Reporter: zhiyuan.dai > Fix For: 0.90.5 > > Attachments: HBase-5075-src.patch > > > regionserver crashed,it is too long time to notify hmaster.when hmaster know > regionserver's shutdown,it is long time to fetch the hlog's lease. > hbase is a online db, availability is very important. > i have a idea to improve availability, monitor node to check regionserver's > pid.if this pid not exsits,i think the rs down,i will delete the znode,and > force close the hlog file. > so the period maybe 100ms. -- 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-5075) regionserver crashed and failover
[ https://issues.apache.org/jira/browse/HBASE-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiyuan.dai updated HBASE-5075: --- Attachment: HBase-5075-src.patch > regionserver crashed and failover > - > > Key: HBASE-5075 > URL: https://issues.apache.org/jira/browse/HBASE-5075 > Project: HBase > Issue Type: Improvement > Components: monitoring, regionserver, replication, zookeeper >Affects Versions: 0.92.1 >Reporter: zhiyuan.dai > Fix For: 0.90.5 > > Attachments: HBase-5075-src.patch > > > regionserver crashed,it is too long time to notify hmaster.when hmaster know > regionserver's shutdown,it is long time to fetch the hlog's lease. > hbase is a online db, availability is very important. > i have a idea to improve availability, monitor node to check regionserver's > pid.if this pid not exsits,i think the rs down,i will delete the znode,and > force close the hlog file. > so the period maybe 100ms. -- 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-5075) regionserver crashed and failover
[ https://issues.apache.org/jira/browse/HBASE-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiyuan.dai updated HBASE-5075: --- Attachment: Degion of Failure Detection.pdf > regionserver crashed and failover > - > > Key: HBASE-5075 > URL: https://issues.apache.org/jira/browse/HBASE-5075 > Project: HBase > Issue Type: Improvement > Components: monitoring, regionserver, replication, zookeeper >Affects Versions: 0.92.1 >Reporter: zhiyuan.dai > Fix For: 0.90.5 > > Attachments: Degion of Failure Detection.pdf, HBase-5075-src.patch > > > regionserver crashed,it is too long time to notify hmaster.when hmaster know > regionserver's shutdown,it is long time to fetch the hlog's lease. > hbase is a online db, availability is very important. > i have a idea to improve availability, monitor node to check regionserver's > pid.if this pid not exsits,i think the rs down,i will delete the znode,and > force close the hlog file. > so the period maybe 100ms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5075) regionserver crashed and failover
[ https://issues.apache.org/jira/browse/HBASE-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211691#comment-13211691 ] zhiyuan.dai commented on HBASE-5075: @stack @Lars Hofhansl First the rpc method getRSPidAndRsZknode is to fetch PID and znode which includes domain and service port,this way is reliable. If we use processes list, there may be some misjudgment. Second there is a supervisor called RegionServerFailureDetection,we first start regionserver, and then start RegionServerFailureDetection.RegionServerFailureDetection is a watchdog of RegionServer. Then the supervisor(RegionServerFailureDetection) of regionserver fetch PID and znode by getRSPidAndRsZknode. RegionServerFailureDetection doesn't have any relationship with long GC. RegionServerFailureDetection first check whether PID is alive and the check service port is alive. > regionserver crashed and failover > - > > Key: HBASE-5075 > URL: https://issues.apache.org/jira/browse/HBASE-5075 > Project: HBase > Issue Type: Improvement > Components: monitoring, regionserver, replication, zookeeper >Affects Versions: 0.92.1 >Reporter: zhiyuan.dai > Fix For: 0.90.5 > > Attachments: Degion of Failure Detection.pdf, HBase-5075-src.patch > > > regionserver crashed,it is too long time to notify hmaster.when hmaster know > regionserver's shutdown,it is long time to fetch the hlog's lease. > hbase is a online db, availability is very important. > i have a idea to improve availability, monitor node to check regionserver's > pid.if this pid not exsits,i think the rs down,i will delete the znode,and > force close the hlog file. > so the period maybe 100ms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5399) Cut the link between the client and the zookeeper ensemble
[ https://issues.apache.org/jira/browse/HBASE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211703#comment-13211703 ] nkeywal commented on HBASE-5399: @Lars and all: done see https://reviews.apache.org/r/3967/ I sent it to the whole hbase group, I hope it's the right thing to do. I'm on vacation this week so I will see the comments after the 27th... > Cut the link between the client and the zookeeper ensemble > -- > > Key: HBASE-5399 > URL: https://issues.apache.org/jira/browse/HBASE-5399 > Project: HBase > Issue Type: Improvement > Components: client >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Attachments: 5399_inprogress.patch, 5399_inprogress.v3.patch, > 5399_inprogress.v9.patch > > > The link is often considered as an issue, for various reasons. One of them > being that there is a limit on the number of connection that ZK can manage. > Stack was suggesting as well to remove the link to master from HConnection. > There are choices to be made considering the existing API (that we don't want > to break). > The first patches I will submit on hadoop-qa should not be committed: they > are here to show the progress on the direction taken. > ZooKeeper is used for: > - public getter, to let the client do whatever he wants, and close ZooKeeper > when closing the connection => we have to deprecate this but keep it. > - read get master address to create a master => now done with a temporary > zookeeper connection > - read root location => now done with a temporary zookeeper connection, but > questionable. Used in public function "locateRegion". To be reworked. > - read cluster id => now done once with a temporary zookeeper connection. > - check if base done is available => now done once with a zookeeper > connection given as a parameter > - isTableDisabled/isTableAvailable => public functions, now done with a > temporary zookeeper connection. > - Called internally from HBaseAdmin and HTable > - getCurrentNrHRS(): public function to get the number of region servers and > create a pool of thread => now done with a temporary zookeeper connection > - > Master is used for: > - getMaster public getter, as for ZooKeeper => we have to deprecate this but > keep it. > - isMasterRunning(): public function, used internally by HMerge & HBaseAdmin > - getHTableDescriptor*: public functions offering access to the master. => > we could make them using a temporary master connection as well. > Main points are: > - hbase class for ZooKeeper; ZooKeeperWatcher is really designed for a > strongly coupled architecture ;-). This can be changed, but requires a lot of > modifications in these classes (likely adding a class in the middle of the > hierarchy, something like that). Anyway, non connected client will always be > really slower, because it's a tcp connection, and establishing a tcp > connection is slow. > - having a link between ZK and all the client seems to make sense for some > Use Cases. However, it won't scale if a TCP connection is required for every > client > - if we move the table descriptor part away from the client, we need to find > a new place for it. > - we will have the same issue if HBaseAdmin (for both ZK & Master), may be we > can put a timeout on the connection. That would make the whole system less > deterministic however. -- 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
