[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: --- 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 ] 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: --- 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 ] 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: --- 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)
[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: --- 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)
