[GitHub] phoenix pull request #278: PHOENIX-4322 DESC primary key column with variabl...
Github user maryannxue closed the pull request at: https://github.com/apache/phoenix/pull/278 ---
[GitHub] phoenix pull request #228: PHOENIX-3355 Register Phoenix built-in functions ...
Github user maryannxue closed the pull request at: https://github.com/apache/phoenix/pull/228 ---
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user maryannxue closed the pull request at: https://github.com/apache/phoenix/pull/281 ---
[GitHub] phoenix issue #308: Client-side hash aggregation
Github user geraldss commented on the issue: https://github.com/apache/phoenix/pull/308 @JamesRTaylor -- ok, I will submit a new PR. Can you comment on my last push and comments? ---
[GitHub] phoenix issue #308: Client-side hash aggregation
Github user JamesRTaylor commented on the issue: https://github.com/apache/phoenix/pull/308 Looks like the move of 5.x branch to become master messed up this PR. Can you please start a new pull request against the 4.x-HBase-1.4 branch (this is what was master before), @geraldss? FYI, the last step will be to get a test run with your patch in place to make sure there are no regressions. To do that, attach a .patch file to the JIRA (include the branch name in the name of the patch file) and click on the Submit Patch button. See http://phoenix.apache.org/contributing.html#Generate_a_patch for more info on that. ---
[GitHub] phoenix issue #316: PHOENIX-3547 Supporting more number of indices per table...
Github user m2je commented on the issue: https://github.com/apache/phoenix/pull/316 I don't know what happened. Let me open a new pull request ---
[GitHub] phoenix pull request #316: PHOENIX-3547 Supporting more number of indices pe...
Github user m2je closed the pull request at: https://github.com/apache/phoenix/pull/316 ---
[GitHub] phoenix issue #313: PHOENIX-4799 Write cells using checkAndMutate to prevent...
Github user twdsilva commented on the issue: https://github.com/apache/phoenix/pull/313 @ankitsinghal I filed PHOENIX-4765 to not allow metadata changes on a base table that has child views when the request is from an older client. This will also allow us to rollback the upgraded server side jar if required. ---
[jira] [Updated] (PHOENIX-4765) Add server side config property to disallow metadata changes that require being propagated to children
[ https://issues.apache.org/jira/browse/PHOENIX-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4765: Description: After the server has been upgraded we will have a server side config property that will allow us to rollback the upgrade if required. This config will: 1. Disallow metadata changes to a base table that require being propagated to child views. If the client is older than the server we also disallow metadata changes to a base table with child views since we no longer lock the parent on the server side. This is handled on the client side in the new jar. 2. Prevent SYSTEM.CATALOG from splitting. was: After the server has been upgraded we will have a server side config property that will allow us to rollback the upgrade if required. This config will: 1. Disallow metadata changes to a base table that require being propagated to child views. 2. Prevent SYSTEM.CATALOG from splitting. > Add server side config property to disallow metadata changes that require > being propagated to children > -- > > Key: PHOENIX-4765 > URL: https://issues.apache.org/jira/browse/PHOENIX-4765 > Project: Phoenix > Issue Type: Sub-task >Reporter: Thomas D'Silva >Priority: Major > > After the server has been upgraded we will have a server side config property > that will allow us to rollback the upgrade if required. This config will: > 1. Disallow metadata changes to a base table that require being propagated to > child views. > If the client is older than the server we also disallow metadata changes to a > base table with child views since we no longer lock the parent on the server > side. This is handled on the client side in the new jar. > 2. Prevent SYSTEM.CATALOG from splitting. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4765) Add server side config property to disallow metadata changes that require being propagated to children
[ https://issues.apache.org/jira/browse/PHOENIX-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4765: Summary: Add server side config property to disallow metadata changes that require being propagated to children (was: Add server side config property to enable rollback (if required)) > Add server side config property to disallow metadata changes that require > being propagated to children > -- > > Key: PHOENIX-4765 > URL: https://issues.apache.org/jira/browse/PHOENIX-4765 > Project: Phoenix > Issue Type: Sub-task >Reporter: Thomas D'Silva >Priority: Major > > After the server has been upgraded we will have a server side config property > that will allow us to rollback the upgrade if required. This config will: > 1. Disallow metadata changes to a base table that require being propagated to > child views. > 2. Prevent SYSTEM.CATALOG from splitting. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] phoenix issue #316: PHOENIX-3547 Supporting more number of indices per table...
Github user twdsilva commented on the issue: https://github.com/apache/phoenix/pull/316 @m2je Thanks for the contribution. Can you please update the PR to use the correct branch. It currently has 250+ commits, so it hard to review your changes. ---
[GitHub] phoenix issue #316: PHOENIX-3547 Supporting more number of indices per table...
Github user twdsilva commented on the issue: https://github.com/apache/phoenix/pull/316 @m2je Thanks for the PR. Can you please update the PR so that it uses the correct branch, so that we can see only your changes? This PR currently has 250+ commits. ---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/315#discussion_r205901029
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java ---
@@ -204,6 +219,39 @@ private static void resetGlobalMetrics() {
}
}
+private boolean verifyMetricsFromSink() throws InterruptedException {
+Map expectedMetrics = new HashMap<>();
+for (GlobalMetric m :
PhoenixRuntime.getGlobalPhoenixClientMetrics()) {
+expectedMetrics.put(m.getMetricType().name(), m.getTotalSum());
+}
+
+for (int i = 0; i < MAX_RETRIES; i++) {
+LOG.info("Verifying Global Metrics from Hadoop Sink, Retry: "
+ (i + 1));
+if (verifyMetricsFromSinkOnce(expectedMetrics)) {
+LOG.info("Values from Hadoop Metrics Sink match actual
values");
+return true;
+}
+Thread.sleep(1000);
+}
+return false;
+}
+
+private boolean verifyMetricsFromSinkOnce(Map
expectedMetrics) {
+synchronized (GlobalPhoenixMetricsTestSink.lock) {
+for (AbstractMetric metric :
GlobalPhoenixMetricsTestSink.metrics) {
+if (expectedMetrics.containsKey(metric.name())) {
--- End diff --
I will also soon add a test that disables these metrics as well.
> I'd switch this around to iterate over your expectations, ensuring that
they all exist.
The reason why I didn't do it that way because I didn't wanted to iterate
over the it for every expected metric. It doesn't really matter since its a
test though. One approach can be to remove each entry from the map and check if
the size is 0 at the end. How does that sound?
---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/315#discussion_r205900530
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/monitoring/GlobalClientMetrics.java
---
@@ -108,40 +114,88 @@
GLOBAL_HBASE_COUNT_ROWS_SCANNED(COUNT_ROWS_SCANNED),
GLOBAL_HBASE_COUNT_ROWS_FILTERED(COUNT_ROWS_FILTERED);
-
+private static final Logger LOG =
LoggerFactory.getLogger(GlobalClientMetrics.class);
private static final boolean isGlobalMetricsEnabled =
QueryServicesOptions.withDefaults().isGlobalMetricsEnabled();
+private MetricType metricType;
private GlobalMetric metric;
-public void update(long value) {
+static {
+initPhoenixGlobalClientMetrics();
if (isGlobalMetricsEnabled) {
-metric.change(value);
+MetricRegistry metricRegistry = createMetricRegistry();
+registerPhoenixMetricsToRegistry(metricRegistry);
+
GlobalMetricRegistriesAdapter.getInstance().registerMetricRegistry(metricRegistry);
+}
+}
+
+private static void initPhoenixGlobalClientMetrics() {
+for (GlobalClientMetrics globalMetric :
GlobalClientMetrics.values()) {
+globalMetric.metric = isGlobalMetricsEnabled ?
+new GlobalMetricImpl(globalMetric.metricType) : new
NoOpGlobalMetricImpl();
+}
+}
+
+private static void registerPhoenixMetricsToRegistry(MetricRegistry
metricRegistry) {
+for (GlobalClientMetrics globalMetric :
GlobalClientMetrics.values()) {
+metricRegistry.register(globalMetric.metricType.columnName(),
+new PhoenixGlobalMetricGauge(globalMetric.metric));
+}
+}
+
+private static MetricRegistry createMetricRegistry() {
+LOG.info("Creating Metric Registry for Phoenix Global Metrics");
+MetricRegistryInfo registryInfo = new
MetricRegistryInfo("PHOENIX", "Phoenix Global Metrics",
--- End diff --
Global here refers that it is an aggregation across all clients (or all
Phoenix Connections).
> Maybe "Phoenix,sub=CLIENT" down below?
Seems reasonable as well.
---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user karanmehta93 commented on a diff in the pull request: https://github.com/apache/phoenix/pull/315#discussion_r205899353 --- Diff: phoenix-core/src/test/resources/hadoop-metrics2.properties --- @@ -32,10 +32,9 @@ #[prefix].[source|sink].[instance].[options] # See javadoc of package-info.java for org.apache.hadoop.metrics2 for detail - -# Don't attempt to start jmx mbeans for all sources. -# For right now, all metrics are exported to a phoenix table -*.source.start_mbeans=false +hbase.source.start_mbeans=true +hbase.sink.sink0.class=org.apache.phoenix.monitoring.GlobalPhoenixMetricsTestSink --- End diff -- Sure. It was hard for me as well since things were not working as expected in the first place. Took a little while to realize this file was the reason :) ---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user joshelser commented on a diff in the pull request: https://github.com/apache/phoenix/pull/315#discussion_r205884608 --- Diff: phoenix-core/src/test/resources/hadoop-metrics2.properties --- @@ -32,10 +32,9 @@ #[prefix].[source|sink].[instance].[options] # See javadoc of package-info.java for org.apache.hadoop.metrics2 for detail - -# Don't attempt to start jmx mbeans for all sources. -# For right now, all metrics are exported to a phoenix table -*.source.start_mbeans=false +hbase.source.start_mbeans=true +hbase.sink.sink0.class=org.apache.phoenix.monitoring.GlobalPhoenixMetricsTestSink --- End diff -- Can you leave a comment in the test that this configuration is here? Otherwise, might seem like voodoo ---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/315#discussion_r205884335
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java ---
@@ -204,6 +219,39 @@ private static void resetGlobalMetrics() {
}
}
+private boolean verifyMetricsFromSink() throws InterruptedException {
+Map expectedMetrics = new HashMap<>();
+for (GlobalMetric m :
PhoenixRuntime.getGlobalPhoenixClientMetrics()) {
+expectedMetrics.put(m.getMetricType().name(), m.getTotalSum());
+}
+
+for (int i = 0; i < MAX_RETRIES; i++) {
+LOG.info("Verifying Global Metrics from Hadoop Sink, Retry: "
+ (i + 1));
+if (verifyMetricsFromSinkOnce(expectedMetrics)) {
+LOG.info("Values from Hadoop Metrics Sink match actual
values");
+return true;
+}
+Thread.sleep(1000);
+}
+return false;
+}
+
+private boolean verifyMetricsFromSinkOnce(Map
expectedMetrics) {
+synchronized (GlobalPhoenixMetricsTestSink.lock) {
+for (AbstractMetric metric :
GlobalPhoenixMetricsTestSink.metrics) {
+if (expectedMetrics.containsKey(metric.name())) {
--- End diff --
This check doesn't catch the case where you have `expectedMetrics` but
`GlobalPhoenixMetricsTestSink.metrics` is empty. I'd switch this around to
iterate over your expectations, ensuring that they all exist.
---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/315#discussion_r205884792
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/monitoring/GlobalClientMetrics.java
---
@@ -108,40 +114,88 @@
GLOBAL_HBASE_COUNT_ROWS_SCANNED(COUNT_ROWS_SCANNED),
GLOBAL_HBASE_COUNT_ROWS_FILTERED(COUNT_ROWS_FILTERED);
-
+private static final Logger LOG =
LoggerFactory.getLogger(GlobalClientMetrics.class);
private static final boolean isGlobalMetricsEnabled =
QueryServicesOptions.withDefaults().isGlobalMetricsEnabled();
+private MetricType metricType;
private GlobalMetric metric;
-public void update(long value) {
+static {
+initPhoenixGlobalClientMetrics();
if (isGlobalMetricsEnabled) {
-metric.change(value);
+MetricRegistry metricRegistry = createMetricRegistry();
+registerPhoenixMetricsToRegistry(metricRegistry);
+
GlobalMetricRegistriesAdapter.getInstance().registerMetricRegistry(metricRegistry);
+}
+}
+
+private static void initPhoenixGlobalClientMetrics() {
+for (GlobalClientMetrics globalMetric :
GlobalClientMetrics.values()) {
+globalMetric.metric = isGlobalMetricsEnabled ?
+new GlobalMetricImpl(globalMetric.metricType) : new
NoOpGlobalMetricImpl();
+}
+}
+
+private static void registerPhoenixMetricsToRegistry(MetricRegistry
metricRegistry) {
+for (GlobalClientMetrics globalMetric :
GlobalClientMetrics.values()) {
+metricRegistry.register(globalMetric.metricType.columnName(),
+new PhoenixGlobalMetricGauge(globalMetric.metric));
+}
+}
+
+private static MetricRegistry createMetricRegistry() {
+LOG.info("Creating Metric Registry for Phoenix Global Metrics");
+MetricRegistryInfo registryInfo = new
MetricRegistryInfo("PHOENIX", "Phoenix Global Metrics",
--- End diff --
What does "Global" mean in this context? Is "Phoenix Client Metrics" more
reasonable? Maybe "Phoenix,sub=CLIENT" down below?
---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/315#discussion_r205884048
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java ---
@@ -204,6 +219,39 @@ private static void resetGlobalMetrics() {
}
}
+private boolean verifyMetricsFromSink() throws InterruptedException {
+Map expectedMetrics = new HashMap<>();
+for (GlobalMetric m :
PhoenixRuntime.getGlobalPhoenixClientMetrics()) {
+expectedMetrics.put(m.getMetricType().name(), m.getTotalSum());
+}
+
+for (int i = 0; i < MAX_RETRIES; i++) {
+LOG.info("Verifying Global Metrics from Hadoop Sink, Retry: "
+ (i + 1));
+if (verifyMetricsFromSinkOnce(expectedMetrics)) {
+LOG.info("Values from Hadoop Metrics Sink match actual
values");
+return true;
+}
+Thread.sleep(1000);
+}
+return false;
+}
+
+private boolean verifyMetricsFromSinkOnce(Map
expectedMetrics) {
+synchronized (GlobalPhoenixMetricsTestSink.lock) {
--- End diff --
If it were me, I would have used a Queue or something to save off the
metrics, but there's nothing wrong with your approach here :)
---
[GitHub] phoenix pull request #316: PHOENIX-3547 Supporting more number of indices pe...
GitHub user m2je opened a pull request: https://github.com/apache/phoenix/pull/316 PHOENIX-3547 Supporting more number of indices per table. PHOENIX-3547 Supporting more number of indices per table. Currently the number of indices per Phoenix table is bound to maximum of 65535 (java.lang.Short) which is a limitation for applications requiring to have unlimited number of indices. This change will consider any new table created in Phoenix to support view index ids to be in the range of -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 (java.lang.Long) which is undoubtably big enough to cover this requirement. Any existing Phoenix table will still continue to support only maximum of 65535 of indices. A new boolean column (USE_LONG_VIEW_INDEX BOOLEAN DEFAULT FALSE) is added to SYSTEM.CATALOG to specify each Phoenix table's support for large number of indices. On each new Phoenix table creation the value for USE_LONG_VIEW_INDEX will be set to `true` while this value would be false for any existing table. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m2je/phoenix PHOENIX-3547 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/phoenix/pull/316.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #316 ---
[jira] [Assigned] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang reassigned PHOENIX-4815:
-
Assignee: Jaanai Zhang
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.12.0
>Reporter: Jaanai Zhang
>Assignee: Jaanai Zhang
>Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
> reference link:
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2103956
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Attachment: PHOENIX-3655.4.x-HBase-1.4.001.patch > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 > Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.4.x-HBase-1.4.001.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Attachment: (was: PHOENIX-3655.001.patch) > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 > Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.4.x-HBase-1.4.001.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Environment: (was: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98) > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.4.x-HBase-1.4.001.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Attachment: (was: PHOENIX-3655.001.diff) > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 > Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.001.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Attachment: PHOENIX-3655.001.patch > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 > Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.001.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] phoenix issue #242: PQS metrics - https://issues.apache.org/jira/browse/PHOE...
Github user karanmehta93 commented on the issue: https://github.com/apache/phoenix/pull/242 We decided not to follow this approach, Hence will be removing the reference to this PR from JIRA. ---
[GitHub] phoenix issue #315: PHOENIX-3655 Global Phoenix Client Metrics for PQS
Github user karanmehta93 commented on the issue: https://github.com/apache/phoenix/pull/315 The patch might be tricky to port to other branches. Will also look into that once the initial one gets in. ---
[GitHub] phoenix pull request #315: PHOENIX-3655 Global Phoenix Client Metrics for PQ...
GitHub user karanmehta93 opened a pull request: https://github.com/apache/phoenix/pull/315 PHOENIX-3655 Global Phoenix Client Metrics for PQS @joshelser Please review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/karanmehta93/phoenix 4.x-HBase-1.4 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/phoenix/pull/315.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #315 commit a8f7f25b57e9e7f6abbbfc2c70bb9648ca872761 Author: Karan Mehta Date: 2018-07-27T08:57:33Z PHOENIX-3655 Global Phoenix Client Metrics for PQS ---
[jira] [Updated] (PHOENIX-3655) Global Phoenix Client Metrics for PQS
[ https://issues.apache.org/jira/browse/PHOENIX-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-3655: - Summary: Global Phoenix Client Metrics for PQS (was: Metrics for PQS) > Global Phoenix Client Metrics for PQS > - > > Key: PHOENIX-3655 > URL: https://issues.apache.org/jira/browse/PHOENIX-3655 > Project: Phoenix > Issue Type: New Feature >Affects Versions: 4.8.0 > Environment: Linux 3.13.0-107-generic kernel, v4.9.0-HBase-0.98 >Reporter: Rahul Shrivastava >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0 > > Attachments: MetricsforPhoenixQueryServerPQS.pdf, > PHOENIX-3655.001.diff > > Original Estimate: 240h > Remaining Estimate: 240h > > Phoenix Query Server runs a separate process compared to its thin client. > Metrics collection is currently done by PhoenixRuntime.java i.e. at Phoenix > driver level. We need the following > 1. For every jdbc statement/prepared statement/ run by PQS , we need > capability to collect metrics at PQS level and push the data to external sink > i.e. file, JMX , other external custom sources. > 2. Besides this global metrics could be periodically collected and pushed to > the sink. > 2. PQS can be configured to turn on metrics collection and type of collect ( > runtime or global) via hbase-site.xml > 3. Sink could be configured via an interface in hbase-site.xml. > All metrics definition https://phoenix.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
