[jira] [Commented] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092026#comment-14092026 ] Anoop Sam John commented on HBASE-11438: IMO we should continue to have validation and should not drop HBASE-10883 fix. Ping [~apurtell]. > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch, > HBASE-11438_v9.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[
https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092021#comment-14092021
]
Hadoop QA commented on HBASE-11438:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660840/HBASE-11438_v9.patch
against trunk revision .
ATTACHMENT ID: 12660840
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 12 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10370//console
This message is automatically generated.
> [Visibility Controller] Support UTF8 character as Visibility Labels
> ---
>
> Key: HBASE-11438
> URL: https://issues.apache.org/jira/browse/HBASE-11438
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.98.4
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 0.98.6
>
> Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch,
> HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch,
> HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch,
> HBASE-11438_v9.patch
>
>
> This would be an action item that we would be addressing so that the
> visibility labels could have UTF8 characters in them. Also allow the user to
> use a client supplied API that allows to specify the visibility labels inside
> double quotes such that UTF8 characters and cases like &, |, ! and double
> quotes itself could be specified with proper escape sequence. Accumulo too
> provides one such API in the client side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11438: --- Status: Open (was: Patch Available) > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch, > HBASE-11438_v9.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11438: --- Status: Patch Available (was: Open) > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch, > HBASE-11438_v9.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11438: --- Attachment: HBASE-11438_v9.patch > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch, > HBASE-11438_v9.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[
https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092016#comment-14092016
]
Hadoop QA commented on HBASE-11438:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660839/HBASE-11438_v8.patch
against trunk revision .
ATTACHMENT ID: 12660839
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 12 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10369//console
This message is automatically generated.
> [Visibility Controller] Support UTF8 character as Visibility Labels
> ---
>
> Key: HBASE-11438
> URL: https://issues.apache.org/jira/browse/HBASE-11438
> Project: HBase
> Issue Type: Improvement
> Components: security
>Affects Versions: 0.98.4
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 0.98.6
>
> Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch,
> HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch,
> HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch
>
>
> This would be an action item that we would be addressing so that the
> visibility labels could have UTF8 characters in them. Also allow the user to
> use a client supplied API that allows to specify the visibility labels inside
> double quotes such that UTF8 characters and cases like &, |, ! and double
> quotes itself could be specified with proper escape sequence. Accumulo too
> provides one such API in the client side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11438: --- Status: Patch Available (was: Open) > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11438: --- Attachment: HBASE-11438_v8.patch Updated the java doc for the quote() api. The change to list of bytes and then String is needed because we skip the "\\" character added by the quote. This is something similar to accumulo. So using the offsets to recreate the string would not work here. A test case is added to test add labels and mutations with unicode characters. There is no change done to the validations part. Is there any updates needed to the patch? > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.6 > > Attachments: HBASE-11438_v1.patch, HBASE-11438_v2.patch, > HBASE-11438_v3.patch, HBASE-11438_v4.patch, HBASE-11438_v5.patch, > HBASE-11438_v6.patch, HBASE-11438_v7.patch, HBASE-11438_v8.patch > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. Also allow the user to > use a client supplied API that allows to specify the visibility labels inside > double quotes such that UTF8 characters and cases like &, |, ! and double > quotes itself could be specified with proper escape sequence. Accumulo too > provides one such API in the client side. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10877) HBase non-retriable exception list should be expanded
[
https://issues.apache.org/jira/browse/HBASE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092011#comment-14092011
]
Guru Medasani commented on HBASE-10877:
---
[~ndimiduk] Thanks for fixing this is HBase 0.98.4.
> HBase non-retriable exception list should be expanded
> -
>
> Key: HBASE-10877
> URL: https://issues.apache.org/jira/browse/HBASE-10877
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Priority: Minor
>
> Example where retries do not make sense:
> {noformat}
> 2014-03-31 20:54:27,765 WARN [InputInitializer [Map 1] #0]
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch hbase:meta table:
> org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after
> attempts=35, exceptions:
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: class
> com.google.protobuf.HBaseZeroCopyByteString cannot access its superclass
> com.google.protobuf.LiteralByteString
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:18 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:20 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:24 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:34 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:55 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:46 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:49:06 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:49:26 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:49:46 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:50:06 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:50:26 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/googl
[jira] [Commented] (HBASE-10877) HBase non-retriable exception list should be expanded
[
https://issues.apache.org/jira/browse/HBASE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092004#comment-14092004
]
Guru Medasani commented on HBASE-10877:
---
Thanks Ted and Nan Zhu. Adding the hbase-protocol-*.jar to the Classpath fixed
my issues as well.
export
SPARK_CLASSPATH=$SPARK_CLASSPATH:/usr/local/Cellar/hbase/0.98.3/libexec/lib/hbase-protocol-0.98.3-hadoop2.jar
scala>
theput.add(Bytes.toBytes("testColumn"),Bytes.toBytes("x"),Bytes.toBytes("y1"))
res1: org.apache.hadoop.hbase.client.Put =
{"totalColumns":1,"families":{"testColumn":[{"timestamp":9223372036854775807,"tag":[],"qualifier":"x","vlen":2}]},"row":"rowKey1"}
scala> table.put(theput)
scala>
No errors this time :)
> HBase non-retriable exception list should be expanded
> -
>
> Key: HBASE-10877
> URL: https://issues.apache.org/jira/browse/HBASE-10877
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Priority: Minor
>
> Example where retries do not make sense:
> {noformat}
> 2014-03-31 20:54:27,765 WARN [InputInitializer [Map 1] #0]
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation:
> Encountered problems when prefetch hbase:meta table:
> org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after
> attempts=35, exceptions:
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: class
> com.google.protobuf.HBaseZeroCopyByteString cannot access its superclass
> com.google.protobuf.LiteralByteString
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:17 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:18 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:20 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:24 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:34 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:45:55 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:46:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:47:45 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:05 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:25 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:48:46 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:49:06 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyByteString
> Mon Mar 31 20:49:26 UTC 2014,
> org.apache.hadoop.hbase.client.RpcRetryingCaller@343d511e,
> java.lang.IllegalAccessError: com/google/protobuf/HBaseZeroCopyB
[jira] [Commented] (HBASE-11703) Meta region state could be corrupted
[ https://issues.apache.org/jira/browse/HBASE-11703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091808#comment-14091808 ] Jimmy Xiang commented on HBASE-11703: - The two failed tests are ok locally, not related to this change. > Meta region state could be corrupted > > > Key: HBASE-11703 > URL: https://issues.apache.org/jira/browse/HBASE-11703 > Project: HBase > Issue Type: Bug >Affects Versions: 0.99.0 >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Attachments: hbase-11703.patch > > > Internal meta region state could be corrupted if the meta is not on master: > 1. the meta region server (not master) shuts down, > 2. meta SSH offlines it without updating the dead server's region list, > 3. meta is transitioned to pending_open and the previous server (the dead > server) of meta is lost, > 4. meta is assigned somewhere else without updating its previous server, > 5. normal SSH processes the dead server and offlines all of it's dead regions > including the meta, so the meta internal state is corrupted -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11604) Disable co-locating meta/master by default
[ https://issues.apache.org/jira/browse/HBASE-11604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091800#comment-14091800 ] Jimmy Xiang commented on HBASE-11604: - For distributed mode, no, we don't. You just need to have region servers on other ports/machines. > Disable co-locating meta/master by default > -- > > Key: HBASE-11604 > URL: https://issues.apache.org/jira/browse/HBASE-11604 > Project: HBase > Issue Type: Task >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 1.0.0 > > Attachments: hbase-11604.patch, hbase-11604_v2.patch > > > To avoid possible confusing, it's better to keep the original deployment > scheme in 1.0. ZK-less region assignment is off by default in 1.0 already. We > should, by default, not assign any region to master or backup master. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091798#comment-14091798
]
louis hust commented on HBASE-11708:
[~busbey], I will modify the ident, thanks for your help.
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
louis hust updated HBASE-11708:
---
Affects Version/s: 0.96.2
0.98.1
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11627) RegionSplitter's rollingSplit terminated with "/ by zero", and the _balancedSplit file was not deleted properly
[
https://issues.apache.org/jira/browse/HBASE-11627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091797#comment-14091797
]
louis hust commented on HBASE-11627:
[~busbey], thanks for your work, and i will focus on HBASE-11708
> RegionSplitter's rollingSplit terminated with "/ by zero", and the
> _balancedSplit file was not deleted properly
> ---
>
> Key: HBASE-11627
> URL: https://issues.apache.org/jira/browse/HBASE-11627
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
> Environment: CentOS release 6.4 (Final) x86_64 &&
> hbase-0.98.1-cdh5.1.0
>Reporter: louis hust
>Assignee: Sean Busbey
> Labels: beginner
> Fix For: 0.99.0, 2.0.0, 0.98.6
>
> Attachments: HBASE_11627-v2.patch, HBASE_11627-v3.patch,
> HBASE_11627-v4.patch, HBASE_11627-v5.patch, HBASE_11627-v6.patch,
> HBASE_11627-v7.patch, HBASE_11627.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> First create a table
> {quote}
> > create 't1', 'f1'
> {quote}
> Then split the table with util:
> {quote}
> > bin/hbase org.apache.hadoop.hbase.util.RegionSplitter -r -o 2 t1
> > UniformSplit
> {quote}
> *Finally get the following error :*
> {quote}
> 12/11/08 19:21:12 DEBUG util.RegionSplitter: All regions have been
> successfully split!
> 12/11/08 19:21:12 DEBUG util.RegionSplitter: TOTAL TIME = 30sec
> 12/11/08 19:21:12 DEBUG util.RegionSplitter: Splits = 0
> Exception in thread "main" java.lang.ArithmeticException: / by zero
> at
> org.apache.hadoop.hbase.util.RegionSplitter.rollingSplit(RegionSplitter.java:576)
> at
> org.apache.hadoop.hbase.util.RegionSplitter.main(RegionSplitter.java:349)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11589) AccessControlException should be a not retriable exception
[
https://issues.apache.org/jira/browse/HBASE-11589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091733#comment-14091733
]
Hudson commented on HBASE-11589:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #417 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/417/])
HBASE-11589 AccessControlException should be a not retriable exception (Qiang
Tian) (apurtell: rev 67c232326d16d64bbd7551ec2ef3c796f365d16e)
*
hbase-client/src/main/java/org/apache/hadoop/hbase/security/AccessDeniedException.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> AccessControlException should be a not retriable exception
> --
>
> Key: HBASE-11589
> URL: https://issues.apache.org/jira/browse/HBASE-11589
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.98.3
> Environment: SLES 11 SP1
>Reporter: Kashif J S
>Assignee: Qiang Tian
> Fix For: 0.99.0, 2.0.0, 0.98.6
>
> Attachments: hbase-11589-master-v1.patch,
> hbase-11589-master-v2.patch, hbase-11589-master.patch
>
>
> RPC server does not handle the AccessControlException thrown by
> authorizeConnection failure properly and in return sends IOException to the
> HBase client.
> Ultimately the client does retries and gets RetriesExhaustedException but
> does not getting any link or information or stack trace about
> AccessControlException.
> In short summary, upon inspection of RPCServer.java, it seems
> for the Listener, the Reader read code as below does not handle
> AccessControlException
> {noformat}
> void doRead(….
> …..
> …..
> try {
> count = c.readAndProcess(); // This readAndProcess method throws
> AccessControlException from processOneRpc(byte[] buf) which is not handled ?
> } catch (InterruptedException ieo) {
> throw ieo;
> } catch (Exception e) {
> LOG.warn(getName() + ": count of bytes read: " + count, e);
> count = -1; //so that the (count < 0) block is executed
> }
> {noformat}
> Below is the client logs if authorizeConnection throws AccessControlException:
> 2014-07-24 19:40:58,768 INFO [main]
> client.HConnectionManager$HConnectionImplementation: getMaster attempt 7 of 7
> failed; no more retrying.
> com.google.protobuf.ServiceException: java.io.IOException: Call to
> host-10-18-40-101/10.18.40.101:6 failed on local exception:
> java.io.EOFException
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1674)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1715)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$BlockingStub.isMasterRunning(MasterProtos.java:42561)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$MasterServiceStubMaker.isMasterRunning(HConnectionManager.java:1688)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$StubMaker.makeStubNoRetries(HConnectionManager.java:1597)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$StubMaker.makeStub(HConnectionManager.java:1623)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$MasterServiceStubMaker.makeStub(HConnectionManager.java:1677)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getKeepAliveMasterService(HConnectionManager.java:1885)
> [...]
> Caused by: java.io.IOException: Call to host-10-18-40-101/10.18.40.101:6
> failed on local exception: java.io.EOFException
> at
> org.apache.hadoop.hbase.ipc.RpcClient.wrapException(RpcClient.java:1485)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1457)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1657)
> ... 254 more
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readInt(DataInputStream.java:375)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.readResponse(RpcClient.java:1072)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.run(RpcClient.java:728)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11705) callQueueSize should be decremented in a fail-fast scenario
[ https://issues.apache.org/jira/browse/HBASE-11705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091734#comment-14091734 ] Hudson commented on HBASE-11705: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #417 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/417/]) HBASE-11705 callQueueSize should be decremented in a fail-fast scenario (Esteban Gutierrez) (apurtell: rev cb4ac0d397a77f03715e431b87c8b67bff7aa18c) * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/CallRunner.java > callQueueSize should be decremented in a fail-fast scenario > --- > > Key: HBASE-11705 > URL: https://issues.apache.org/jira/browse/HBASE-11705 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.0, 0.99.0, 2.0.0 >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez >Priority: Critical > Fix For: 0.99.0, 2.0.0, 0.98.6 > > Attachments: HBASE-11705.patch, HBASE-11705.v1.patch, > HBASE-11705.v2.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw). If a client disconnects the > call queue size is not decremented causing new calls to get rejected with a > CallQueueTooBigException. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11706) Set versions for VerifyReplication
[ https://issues.apache.org/jira/browse/HBASE-11706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091735#comment-14091735 ] Hudson commented on HBASE-11706: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #417 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/417/]) HBASE-11706 Set versions for VerifyReplication (cuijianwei) (apurtell: rev b7b1d01e05ec5d966b2bf6d82831137f48159bfb) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/replication/VerifyReplication.java > Set versions for VerifyReplication > -- > > Key: HBASE-11706 > URL: https://issues.apache.org/jira/browse/HBASE-11706 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 0.98.5 >Reporter: cuijianwei >Assignee: cuijianwei >Priority: Minor > Fix For: 0.99.0, 2.0.0, 0.98.6 > > Attachments: HBASE-11706-trunk.patch > > > Currently, there is no argument to set versions for VerifyReplication tool. > It might be useful to have such argument if we want to verify multi-versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091713#comment-14091713 ] Qiang Tian commented on HBASE-11714: the rpc timeout value transmission in the master branch and 1.0 branch is different. the patch is for 0.98 only(the timeout is passed via createBlockingRpcChannel, e.g. HConnectionImplementation) > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > Attachments: hbase-11714-0.98.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Description: Discussed on the user@hbase mailing list (http://markmail.org/thread/w3cqjxwo2smkn2jw) "Recently switched from 0.94 and 0.98, and finding that periodically things are having issues - lots of retry exceptions" : 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, last exception: java.net.SocketTimeoutException: Call to ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed because java.net.SocketTimeoutException: 2000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 ops. there are 2 methods in RpcRetryingCaller: callWithRetries and callWithoutRetries. it looks the timeout setup of callWithRetries is good, while callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a valid timeout, but callWithoutRetries still calls beforeCall, which looks a method for callWithRetries only, to set timeout. since RpcRetryingCaller#callTimeout is not set, thread local timeout is set to 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final pinginterval set to the socket. when there are heavy write workload and the rpc cannot complete in 2s, the client close the connection, so the server side connection is reset and finally exposes the problem in HBASE-11705 was: Discussed on the user@hbase mailing list (http://markmail.org/thread/w3cqjxwo2smkn2jw) "Recently switched from 0.94 and 0.98, and finding that periodically things are having issues - lots of retry exceptions" : 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, last exception: java.net.SocketTimeoutException: Call to ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed because java.net.SocketTimeoutException: 2000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 ops. there are 2 methods in RpcRetryingCaller: callWithRetries and callWithoutRetries. it looks the timeout setup of callWithRetries is good, while callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a valid timeout, but callWithoutRetries still calls beforeCall, which looks a method for callWithRetries only, to set timeout. since RpcRetryingCaller#callTimeout is not set, thread local timeout is set to 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final pinginterval set to the socket. when there are heavy write workload and the rpc cannot complete in 2s, the client close the connection, so the server side connection is reset and finally cause problem in HBASE-11705 > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > Attachments: hbase-11714-0.98.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetri
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Attachment: hbase-11714-0.98.patch > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > Attachments: hbase-11714-0.98.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091707#comment-14091707 ] Qiang Tian commented on HBASE-11714: click wrong button before filling in the info...just added more info. > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Component/s: IPC/RPC > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Affects Version/s: 0.98.3 > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian reassigned HBASE-11714: -- Assignee: Qiang Tian > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug >Reporter: Qiang Tian >Assignee: Qiang Tian > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Description: Discussed on the user@hbase mailing list (http://markmail.org/thread/w3cqjxwo2smkn2jw) "Recently switched from 0.94 and 0.98, and finding that periodically things are having issues - lots of retry exceptions" : 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, last exception: java.net.SocketTimeoutException: Call to ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed because java.net.SocketTimeoutException: 2000 millis timeout while waiting for channel to be ready for read. ch : java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 ops. there are 2 methods in RpcRetryingCaller: callWithRetries and callWithoutRetries. it looks the timeout setup of callWithRetries is good, while callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a valid timeout, but callWithoutRetries still calls beforeCall, which looks a method for callWithRetries only, to set timeout. since RpcRetryingCaller#callTimeout is not set, thread local timeout is set to 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final pinginterval set to the socket. when there are heavy write workload and the rpc cannot complete in 2s, the client close the connection, so the server side connection is reset and finally cause problem in HBASE-11705 > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug >Reporter: Qiang Tian > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally cause problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qiang Tian updated HBASE-11714: --- Summary: RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly (was: batch mutationRpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly) > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug >Reporter: Qiang Tian > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11714) batch mutationRpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
Qiang Tian created HBASE-11714: -- Summary: batch mutationRpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly Key: HBASE-11714 URL: https://issues.apache.org/jira/browse/HBASE-11714 Project: HBase Issue Type: Bug Reporter: Qiang Tian -- This message was sent by Atlassian JIRA (v6.2#6252)
