[jira] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-9990: -- Fix Version/s: 0.98.1 Committed to 0.98 branch also, thanks! > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Attachment: 9990.v2.98.patch > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Fix Version/s: 0.99.0 > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Status: Patch Available (was: Open) > 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.96.0, 0.98.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Attachment: 9990.v2.patch > 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 > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-9990: -- Fix Version/s: (was: 0.96.1) (was: 0.98.0) Status: Open (was: Patch Available) Stale patch, cancelling and unscheduling. > 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.96.0, 0.98.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Status: Open (was: Patch Available) > 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.96.0, 0.98.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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Status: Patch Available (was: Open) > 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.96.0, 0.98.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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Attachment: 9990.v1.patch > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Attachment: (was: 9990.v1.patch) > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Description: 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". was: You can construct a RpcRetryingCallerFactory, but actually the conf is read for each call. 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. > 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] [Updated] (HBASE-9990) HTable uses the conf for each "newCaller"
[ https://issues.apache.org/jira/browse/HBASE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-9990: --- Summary: HTable uses the conf for each "newCaller" (was: RpcRetryingCallerFactory uses the conf for each "newCaller") > 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 call. 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 message was sent by Atlassian JIRA (v6.1#6144)
