[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922692#comment-13922692 ] Hudson commented on HBASE-9990: --- FAILURE: Integrated in HBase-0.98 #206 (See [https://builds.apache.org/job/HBase-0.98/206/]) HBASE-9990 HTable uses the conf for each newCaller (Nicolas Liochon) (apurtell: rev 1574772) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerFactory.java * /hbase/branches/0.98/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.98.1, 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.98.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922365#comment-13922365 ] Hudson commented on HBASE-9990: --- FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #191 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/191/]) HBASE-9990 HTable uses the conf for each newCaller (Nicolas Liochon) (apurtell: rev 1574772) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerFactory.java * /hbase/branches/0.98/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.98.1, 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.98.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918216#comment-13918216 ] Nicolas Liochon commented on HBASE-9990: 9990.v2.98.patch is for the .98 branch. > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.98.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918202#comment-13918202 ] Nicolas Liochon commented on HBASE-9990: For this one, no reason at all. Let me check if the patch applies to the 98 branch. > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918016#comment-13918016 ] Andrew Purtell commented on HBASE-9990: --- Any reason not to move the simple changes that save some time and resources like this and HBASE-10080 into 0.98.1? > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915316#comment-13915316 ] Hudson commented on HBASE-9990: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #101 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/101/]) HBASE-9990 HTable uses the conf for each call creation (nkeywal: rev 1572522) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerFactory.java * /hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915301#comment-13915301 ] Hudson commented on HBASE-9990: --- FAILURE: Integrated in HBase-TRUNK #4964 (See [https://builds.apache.org/job/HBase-TRUNK/4964/]) HBASE-9990 HTable uses the conf for each call creation (nkeywal: rev 1572522) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCallerFactory.java * /hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914419#comment-13914419 ] Nicolas Liochon commented on HBASE-9990: Committed to trunk. > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913695#comment-13913695 ] Nicolas Liochon commented on HBASE-9990: TestLogRolling passes locally. I will commit with the fix on 'stored' tomorrow. Thanks for the review, Ted & Enis! > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[
https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913580#comment-13913580
]
Enis Soztutar commented on HBASE-9990:
--
+1.
One nit is:
{code}
+// We stored the values in the factory instance. This way, constructing
new objects
{code}
stored should be store?
> HTable uses the conf for each "newCaller"
> -
>
> Key: HBASE-9990
> URL: https://issues.apache.org/jira/browse/HBASE-9990
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 9990.v1.patch, 9990.v2.patch
>
>
> You can construct a RpcRetryingCallerFactory, but actually the conf is read
> for each caller creation. Reading the conf is obviously expensive, and a
> profiling session shows it. If we want to sent hundreds of thousands of
> queries per second, we should not do that.
> RpcRetryingCallerFactory.newCaller is called for each get, for example.
> This is not a regression, we have something similar in 0.94.
> On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after
> a few thousand calls to "get".
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913567#comment-13913567 ] Ted Yu commented on HBASE-9990: --- lgtm > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[
https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913553#comment-13913553
]
Hadoop QA commented on HBASE-9990:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12631287/9990.v2.patch
against trunk revision .
ATTACHMENT ID: 12631287
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling.testLogRollOnDatanodeDeath(TestLogRolling.java:354)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8821//console
This message is automatically generated.
> HTable uses the conf for each "newCaller"
> -
>
> Key: HBASE-9990
> URL: https://issues.apache.org/jira/browse/HBASE-9990
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 9990.v1.patch, 9990.v2.patch
>
>
> You can construct a RpcRetryingCallerFactory, but actually the conf is read
> for each caller creation. Reading the conf is obviously expensive, and a
> profiling session shows it. If we want to sent hundreds of thousands of
> queries per second, we should not do that.
> RpcRetryingCallerFactory.newCaller is called for each get, for example.
> This is not a regression, we have something similar in 0.94.
> On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after
> a few thousand calls to "get".
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913188#comment-13913188 ] Nicolas Liochon commented on HBASE-9990: v2: much simpler. > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 9990.v1.patch, 9990.v2.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[
https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825744#comment-13825744
]
Hadoop QA commented on HBASE-9990:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12614448/9990.v1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. 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.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
10 warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/7921//console
This message is automatically generated.
> HTable uses the conf for each "newCaller"
> -
>
> Key: HBASE-9990
> URL: https://issues.apache.org/jira/browse/HBASE-9990
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
> Fix For: 0.98.0, 0.96.1
>
> Attachments: 9990.v1.patch
>
>
> You can construct a RpcRetryingCallerFactory, but actually the conf is read
> for each caller creation. Reading the conf is obviously expensive, and a
> profiling session shows it. If we want to sent hundreds of thousands of
> queries per second, we should not do that.
> RpcRetryingCallerFactory.newCaller is called for each get, for example.
> This is not a regression, we have something similar in 0.94.
> On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after
> a few thousand calls to "get".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[
https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825585#comment-13825585
]
Hadoop QA commented on HBASE-9990:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12614442/9990.v1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. 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.
{color:red}-1 hadoop1.0{color}. The patch failed to compile against the
hadoop 1.0 profile.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/7920//console
This message is automatically generated.
> HTable uses the conf for each "newCaller"
> -
>
> Key: HBASE-9990
> URL: https://issues.apache.org/jira/browse/HBASE-9990
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
> Fix For: 0.98.0, 0.96.1
>
> Attachments: 9990.v1.patch
>
>
> You can construct a RpcRetryingCallerFactory, but actually the conf is read
> for each caller creation. Reading the conf is obviously expensive, and a
> profiling session shows it. If we want to sent hundreds of thousands of
> queries per second, we should not do that.
> RpcRetryingCallerFactory.newCaller is called for each get, for example.
> This is not a regression, we have something similar in 0.94.
> On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after
> a few thousand calls to "get".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825583#comment-13825583 ] Nicolas Liochon commented on HBASE-9990: v1: The 'clone' is far from perfect, but let's see how hadoop qa reacts. > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.96.1 > > Attachments: 9990.v1.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825582#comment-13825582 ] Ted Yu commented on HBASE-9990: --- +1 > HTable uses the conf for each "newCaller" > - > > Key: HBASE-9990 > URL: https://issues.apache.org/jira/browse/HBASE-9990 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.98.0, 0.96.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.96.1 > > Attachments: 9990.v1.patch > > > You can construct a RpcRetryingCallerFactory, but actually the conf is read > for each caller creation. Reading the conf is obviously expensive, and a > profiling session shows it. If we want to sent hundreds of thousands of > queries per second, we should not do that. > RpcRetryingCallerFactory.newCaller is called for each get, for example. > This is not a regression, we have something similar in 0.94. > On the 0.96, we see the creation of: java.util.regex.Matcher: 15739712b after > a few thousand calls to "get". -- This message was sent by Atlassian JIRA (v6.1#6144)
