[jira] [Commented] (PHOENIX-153) Implement TABLESAMPLE clause
[ https://issues.apache.org/jira/browse/PHOENIX-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110284#comment-16110284 ] Ethan Wang commented on PHOENIX-153: Thanks [~jamestaylor]! > Implement TABLESAMPLE clause > > > Key: PHOENIX-153 > URL: https://issues.apache.org/jira/browse/PHOENIX-153 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Ethan Wang > Labels: enhancement > Fix For: 4.12.0 > > Attachments: Sampling_Accuracy_Performance.jpg > > > Support the standard SQL TABLESAMPLE clause by implementing a filter that > uses a skip next hint based on the region boundaries of the table to only > return n rows per region. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4057) Do not issue index updates for out of order mutation
[ https://issues.apache.org/jira/browse/PHOENIX-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor reassigned PHOENIX-4057: - Assignee: James Taylor Fix Version/s: 4.11.1 4.12.0 > Do not issue index updates for out of order mutation > > > Key: PHOENIX-4057 > URL: https://issues.apache.org/jira/browse/PHOENIX-4057 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.12.0, 4.11.1 > > Attachments: PHOENIX-4057_v1.patch, PHOENIX-4057_wip1.patch > > > Index maintenance is not correct when rows arrive out of order (see > PHOENIX-4052). In particular, out of order deletes end up with a spurious Put > in the index. Rather than corrupt the secondary index, we can instead just > ignore out-of-order mutations. The only downside is that point-in-time > queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4057) Do not issue index updates for out of order mutation
[ https://issues.apache.org/jira/browse/PHOENIX-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4057: -- Attachment: (was: PHOENIX-4057_v1.patch) > Do not issue index updates for out of order mutation > > > Key: PHOENIX-4057 > URL: https://issues.apache.org/jira/browse/PHOENIX-4057 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.12.0, 4.11.1 > > Attachments: PHOENIX-4057_v1.patch, PHOENIX-4057_wip1.patch > > > Index maintenance is not correct when rows arrive out of order (see > PHOENIX-4052). In particular, out of order deletes end up with a spurious Put > in the index. Rather than corrupt the secondary index, we can instead just > ignore out-of-order mutations. The only downside is that point-in-time > queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4057) Do not issue index updates for out of order mutation
[ https://issues.apache.org/jira/browse/PHOENIX-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4057: -- Attachment: PHOENIX-4057_v1.patch > Do not issue index updates for out of order mutation > > > Key: PHOENIX-4057 > URL: https://issues.apache.org/jira/browse/PHOENIX-4057 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: James Taylor > Fix For: 4.12.0, 4.11.1 > > Attachments: PHOENIX-4057_v1.patch, PHOENIX-4057_wip1.patch > > > Index maintenance is not correct when rows arrive out of order (see > PHOENIX-4052). In particular, out of order deletes end up with a spurious Put > in the index. Rather than corrupt the secondary index, we can instead just > ignore out-of-order mutations. The only downside is that point-in-time > queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4057) Do not issue index updates for out of order mutation
[ https://issues.apache.org/jira/browse/PHOENIX-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4057: -- Attachment: PHOENIX-4057_v1.patch Patch that prevents index updates for out-of-order rows (since the index was already done for the newer rows). Attempts to make minimal changes to Indexer code since it would be nice to get it working correctly so that point in time queries will work. If we give up on that, we can simplify the indexing code substantially. Please review, [~vincentpoon] and/or [~samarthjain]. [~mujtabachohan] - would you mind giving this patch a try? > Do not issue index updates for out of order mutation > > > Key: PHOENIX-4057 > URL: https://issues.apache.org/jira/browse/PHOENIX-4057 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor > Attachments: PHOENIX-4057_v1.patch, PHOENIX-4057_wip1.patch > > > Index maintenance is not correct when rows arrive out of order (see > PHOENIX-4052). In particular, out of order deletes end up with a spurious Put > in the index. Rather than corrupt the secondary index, we can instead just > ignore out-of-order mutations. The only downside is that point-in-time > queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4057) Do not issue index updates for out of order mutation
[ https://issues.apache.org/jira/browse/PHOENIX-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4057: -- Attachment: PHOENIX-4057_wip1.patch > Do not issue index updates for out of order mutation > > > Key: PHOENIX-4057 > URL: https://issues.apache.org/jira/browse/PHOENIX-4057 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor > Attachments: PHOENIX-4057_wip1.patch > > > Index maintenance is not correct when rows arrive out of order (see > PHOENIX-4052). In particular, out of order deletes end up with a spurious Put > in the index. Rather than corrupt the secondary index, we can instead just > ignore out-of-order mutations. The only downside is that point-in-time > queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4057) Do not issue index updates for out of order mutation
James Taylor created PHOENIX-4057: - Summary: Do not issue index updates for out of order mutation Key: PHOENIX-4057 URL: https://issues.apache.org/jira/browse/PHOENIX-4057 Project: Phoenix Issue Type: Bug Reporter: James Taylor Index maintenance is not correct when rows arrive out of order (see PHOENIX-4052). In particular, out of order deletes end up with a spurious Put in the index. Rather than corrupt the secondary index, we can instead just ignore out-of-order mutations. The only downside is that point-in-time queries against an index will not work correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] phoenix pull request #236: PHOENIX-3654 Load Balancer for thin client
Github user rahulsIOT commented on a diff in the pull request: https://github.com/apache/phoenix/pull/236#discussion_r130728526 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java --- @@ -284,14 +288,18 @@ public static final int DEFAULT_COLUMN_ENCODED_BYTES = QualifierEncodingScheme.TWO_BYTE_QUALIFIERS.getSerializedMetadataValue(); public static final String DEFAULT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS.toString(); public static final String DEFAULT_MULTITENANT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.ONE_CELL_PER_COLUMN.toString(); +public final static String DEFAULT_PHOENIX_QUERY_SERVER_CLUSTER_BASE_PATH = "/phoenix"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_SERVICE_NAME = "queryserver"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_USERNAME = "phoenixuser"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_PASSWORD = "Xsjdhxsd"; --- End diff -- ok. We need to file a doc bug with the details about LB and its limitations. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] phoenix pull request #236: PHOENIX-3654 Load Balancer for thin client
Github user joshelser commented on a diff in the pull request: https://github.com/apache/phoenix/pull/236#discussion_r130726475 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java --- @@ -284,14 +288,18 @@ public static final int DEFAULT_COLUMN_ENCODED_BYTES = QualifierEncodingScheme.TWO_BYTE_QUALIFIERS.getSerializedMetadataValue(); public static final String DEFAULT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS.toString(); public static final String DEFAULT_MULTITENANT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.ONE_CELL_PER_COLUMN.toString(); +public final static String DEFAULT_PHOENIX_QUERY_SERVER_CLUSTER_BASE_PATH = "/phoenix"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_SERVICE_NAME = "queryserver"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_USERNAME = "phoenixuser"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_PASSWORD = "Xsjdhxsd"; --- End diff -- > I replied saying that we can close this PR and open another ticket, where I will fix the SASL ACLs. Implementing SASL acls is one thing -- my above comment was about not forgetting to document the lack of initial support (much less the feature itself). We should make sure that a documentation issue gets filed, not that you build something that rots because no one knows how to use it! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-3654) Load Balancer for thin client
[ https://issues.apache.org/jira/browse/PHOENIX-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109747#comment-16109747 ] ASF GitHub Bot commented on PHOENIX-3654: - Github user joshelser commented on a diff in the pull request: https://github.com/apache/phoenix/pull/236#discussion_r130726475 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java --- @@ -284,14 +288,18 @@ public static final int DEFAULT_COLUMN_ENCODED_BYTES = QualifierEncodingScheme.TWO_BYTE_QUALIFIERS.getSerializedMetadataValue(); public static final String DEFAULT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS.toString(); public static final String DEFAULT_MULTITENANT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.ONE_CELL_PER_COLUMN.toString(); +public final static String DEFAULT_PHOENIX_QUERY_SERVER_CLUSTER_BASE_PATH = "/phoenix"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_SERVICE_NAME = "queryserver"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_USERNAME = "phoenixuser"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_PASSWORD = "Xsjdhxsd"; --- End diff -- > I replied saying that we can close this PR and open another ticket, where I will fix the SASL ACLs. Implementing SASL acls is one thing -- my above comment was about not forgetting to document the lack of initial support (much less the feature itself). We should make sure that a documentation issue gets filed, not that you build something that rots because no one knows how to use it! > Load Balancer for thin client > - > > Key: PHOENIX-3654 > URL: https://issues.apache.org/jira/browse/PHOENIX-3654 > 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: Rahul Shrivastava > Attachments: LoadBalancerDesign.pdf, Loadbalancer.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > We have been having internal discussion on load balancer for thin client for > PQS. The general consensus we have is to have an embedded load balancer with > the thin client instead of using external load balancer such as haproxy. The > idea is to not to have another layer between client and PQS. This reduces > operational cost for system, which currently leads to delay in executing > projects. > But this also comes with challenge of having an embedded load balancer which > can maintain sticky sessions, do fair load balancing knowing the load > downstream of PQS server. In addition, load balancer needs to know location > of multiple PQS server. Now, the thin client needs to keep track of PQS > servers via zookeeper ( or other means). > In the new design, the client ( PQS client) , it is proposed to have an > embedded load balancer. > Where will the load Balancer sit ? > The load load balancer will embedded within the app server client. > How will the load balancer work ? > Load balancer will contact zookeeper to get location of PQS. In this case, > PQS needs to register to ZK itself once it comes online. Zookeeper location > is in hbase-site.xml. It will maintain a small cache of connection to the > PQS. When a request comes in, it will check for an open connection from the > cache. > How will load balancer know load on PQS ? > To start with, it will pick a random open connection to PQS. This means that > load balancer does not know PQS load. Later , we can augment the code so that > thin client can receive load info from PQS and make intelligent decisions. > How will load balancer maintain sticky sessions ? > While we still need to investigate how to implement sticky sessions. We can > look for some open source implementation for the same. > How will PQS register itself to service locator ? > PQS will have location of zookeeper in hbase-site.xml and it would register > itself to the zookeeper. Thin client will find out PQS location using > zookeeper. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-3654) Load Balancer for thin client
[ https://issues.apache.org/jira/browse/PHOENIX-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109739#comment-16109739 ] ASF GitHub Bot commented on PHOENIX-3654: - Github user rahulsIOT commented on a diff in the pull request: https://github.com/apache/phoenix/pull/236#discussion_r130725729 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java --- @@ -284,14 +288,18 @@ public static final int DEFAULT_COLUMN_ENCODED_BYTES = QualifierEncodingScheme.TWO_BYTE_QUALIFIERS.getSerializedMetadataValue(); public static final String DEFAULT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS.toString(); public static final String DEFAULT_MULTITENANT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.ONE_CELL_PER_COLUMN.toString(); +public final static String DEFAULT_PHOENIX_QUERY_SERVER_CLUSTER_BASE_PATH = "/phoenix"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_SERVICE_NAME = "queryserver"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_USERNAME = "phoenixuser"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_PASSWORD = "Xsjdhxsd"; --- End diff -- I think you mentioned SASL ACLs before,and I replied saying that we can close this PR and open another ticket, where I will fix the SASL ACLs. > Load Balancer for thin client > - > > Key: PHOENIX-3654 > URL: https://issues.apache.org/jira/browse/PHOENIX-3654 > 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: Rahul Shrivastava > Attachments: LoadBalancerDesign.pdf, Loadbalancer.patch > > Original Estimate: 240h > Remaining Estimate: 240h > > We have been having internal discussion on load balancer for thin client for > PQS. The general consensus we have is to have an embedded load balancer with > the thin client instead of using external load balancer such as haproxy. The > idea is to not to have another layer between client and PQS. This reduces > operational cost for system, which currently leads to delay in executing > projects. > But this also comes with challenge of having an embedded load balancer which > can maintain sticky sessions, do fair load balancing knowing the load > downstream of PQS server. In addition, load balancer needs to know location > of multiple PQS server. Now, the thin client needs to keep track of PQS > servers via zookeeper ( or other means). > In the new design, the client ( PQS client) , it is proposed to have an > embedded load balancer. > Where will the load Balancer sit ? > The load load balancer will embedded within the app server client. > How will the load balancer work ? > Load balancer will contact zookeeper to get location of PQS. In this case, > PQS needs to register to ZK itself once it comes online. Zookeeper location > is in hbase-site.xml. It will maintain a small cache of connection to the > PQS. When a request comes in, it will check for an open connection from the > cache. > How will load balancer know load on PQS ? > To start with, it will pick a random open connection to PQS. This means that > load balancer does not know PQS load. Later , we can augment the code so that > thin client can receive load info from PQS and make intelligent decisions. > How will load balancer maintain sticky sessions ? > While we still need to investigate how to implement sticky sessions. We can > look for some open source implementation for the same. > How will PQS register itself to service locator ? > PQS will have location of zookeeper in hbase-site.xml and it would register > itself to the zookeeper. Thin client will find out PQS location using > zookeeper. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] phoenix pull request #236: PHOENIX-3654 Load Balancer for thin client
Github user rahulsIOT commented on a diff in the pull request: https://github.com/apache/phoenix/pull/236#discussion_r130725729 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java --- @@ -284,14 +288,18 @@ public static final int DEFAULT_COLUMN_ENCODED_BYTES = QualifierEncodingScheme.TWO_BYTE_QUALIFIERS.getSerializedMetadataValue(); public static final String DEFAULT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS.toString(); public static final String DEFAULT_MULTITENANT_IMMUTABLE_STORAGE_SCHEME = ImmutableStorageScheme.ONE_CELL_PER_COLUMN.toString(); +public final static String DEFAULT_PHOENIX_QUERY_SERVER_CLUSTER_BASE_PATH = "/phoenix"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_SERVICE_NAME = "queryserver"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_USERNAME = "phoenixuser"; +public final static String DEFAULT_PHOENIX_QUERY_SERVER_ZK_ACL_PASSWORD = "Xsjdhxsd"; --- End diff -- I think you mentioned SASL ACLs before,and I replied saying that we can close this PR and open another ticket, where I will fix the SASL ACLs. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-153) Implement TABLESAMPLE clause
[ https://issues.apache.org/jira/browse/PHOENIX-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109722#comment-16109722 ] Hudson commented on PHOENIX-153: FAILURE: Integrated in Jenkins build Phoenix-master #1725 (See [https://builds.apache.org/job/Phoenix-master/1725/]) PHOENIX-153 Implement TABLESAMPLE clause (Ethan Wang) (jamestaylor: rev 5e33dc12bc088bd0008d89f0a5cd7d5c368efa25) * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/ParseNodeFactory.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/optimize/QueryOptimizer.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/FilterableStatement.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/iterate/BaseResultIterators.java * (add) phoenix-core/src/main/java/org/apache/phoenix/iterate/TableSamplerPredicate.java * (add) phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryWithTableSampleIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/compile/JoinCompiler.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/SelectStatement.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/DeleteStatement.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/ConcreteTableNode.java * (edit) phoenix-core/src/main/antlr3/PhoenixSQL.g * (edit) phoenix-core/src/main/java/org/apache/phoenix/parse/NamedTableNode.java > Implement TABLESAMPLE clause > > > Key: PHOENIX-153 > URL: https://issues.apache.org/jira/browse/PHOENIX-153 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Ethan Wang > Labels: enhancement > Fix For: 4.12.0 > > Attachments: Sampling_Accuracy_Performance.jpg > > > Support the standard SQL TABLESAMPLE clause by implementing a filter that > uses a skip next hint based on the region boundaries of the table to only > return n rows per region. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-153) Implement TABLESAMPLE clause
[ https://issues.apache.org/jira/browse/PHOENIX-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109519#comment-16109519 ] James Taylor commented on PHOENIX-153: -- +1. Nice work, [~aertoria]. Will let you know if patch doesn't apply cleanly to other 4.x branches. > Implement TABLESAMPLE clause > > > Key: PHOENIX-153 > URL: https://issues.apache.org/jira/browse/PHOENIX-153 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Ethan Wang > Labels: enhancement > Attachments: Sampling_Accuracy_Performance.jpg > > > Support the standard SQL TABLESAMPLE clause by implementing a filter that > uses a skip next hint based on the region boundaries of the table to only > return n rows per region. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4022) Add PhoenixMetricsLog interface that can be used to log metrics for queries and mutations.
[ https://issues.apache.org/jira/browse/PHOENIX-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109497#comment-16109497 ] Thomas D'Silva commented on PHOENIX-4022: - Sorry about that, I have committed a fix. > Add PhoenixMetricsLog interface that can be used to log metrics for queries > and mutations. > --- > > Key: PHOENIX-4022 > URL: https://issues.apache.org/jira/browse/PHOENIX-4022 > Project: Phoenix > Issue Type: New Feature >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.12.0 > > Attachments: PHOENIX-4022.patch, PHOENIX-4022-v2.patch, > PHOENIX-4022-v3.patch, PHOENIX-4022-v4.patch > > > Create a wrapper for PhoenixConnection, PhoenixStatement, > PhoenixPreparedStatement and PhoenixResultSet that automatically calls the > PhoenixMetricsLog logging methods so users don't have to instrument this > themselves. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4022) Add PhoenixMetricsLog interface that can be used to log metrics for queries and mutations.
[ https://issues.apache.org/jira/browse/PHOENIX-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109410#comment-16109410 ] Samarth Jain commented on PHOENIX-4022: --- [~tdsilva] - looks like your commit broke compilation. https://builds.apache.org/blue/organizations/jenkins/Phoenix-4.x-HBase-0.98/detail/Phoenix-4.x-HBase-0.98/1585/pipeline > Add PhoenixMetricsLog interface that can be used to log metrics for queries > and mutations. > --- > > Key: PHOENIX-4022 > URL: https://issues.apache.org/jira/browse/PHOENIX-4022 > Project: Phoenix > Issue Type: New Feature >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.12.0 > > Attachments: PHOENIX-4022.patch, PHOENIX-4022-v2.patch, > PHOENIX-4022-v3.patch, PHOENIX-4022-v4.patch > > > Create a wrapper for PhoenixConnection, PhoenixStatement, > PhoenixPreparedStatement and PhoenixResultSet that automatically calls the > PhoenixMetricsLog logging methods so users don't have to instrument this > themselves. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4056) java.lang.IllegalArgumentException: Can not create a Path from an empty string
Jepson created PHOENIX-4056:
---
Summary: java.lang.IllegalArgumentException: Can not create a Path
from an empty string
Key: PHOENIX-4056
URL: https://issues.apache.org/jira/browse/PHOENIX-4056
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.11.0
Environment: CDH5.12
Phoenix:4.11
HBase:1.2
phoenix-spark.version:4.11.0-HBase-1.2
Reporter: Jepson
1.use the configuration of server and client(scala project)
phoenix.schema.isNamespaceMappingEnabled
true
phoenix.schema.mapSystemTablesToNamespace
true
2.The Code:
{code:java}
resultDF.write
.format("org.apache.phoenix.spark")
.mode(SaveMode.Overwrite)
.option("table", "JYDW.ADDRESS_ORDERCOUNT")
.option("zkUrl","192.168.1.40,192.168.1.41,192.168.1.42:2181")
.save()
{code}
3.Throw this error,help to fix it,thankyou :
7/08/02 01:07:25 INFO DAGScheduler: Job 6 finished: runJob at
SparkHadoopMapReduceWriter.scala:88, took 7.990715 s
17/08/02 01:07:25 ERROR SparkHadoopMapReduceWriter: Aborting job
job_20170802010717_0079.
{color:#59afe1}*java.lang.IllegalArgumentException: Can not create a Path from
an empty string*{color}
at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
at org.apache.hadoop.fs.Path.(Path.java:134)
at org.apache.hadoop.fs.Path.(Path.java:88)
at
org.apache.spark.internal.io.HadoopMapReduceCommitProtocol.absPathStagingDir(HadoopMapReduceCommitProtocol.scala:58)
at
org.apache.spark.internal.io.HadoopMapReduceCommitProtocol.commitJob(HadoopMapReduceCommitProtocol.scala:132)
at
org.apache.spark.internal.io.SparkHadoopMapReduceWriter$.write(SparkHadoopMapReduceWriter.scala:101)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1.apply$mcV$sp(PairRDDFunctions.scala:1085)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1.apply(PairRDDFunctions.scala:1085)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopDataset$1.apply(PairRDDFunctions.scala:1085)
at
org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at
org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:112)
at org.apache.spark.rdd.RDD.withScope(RDD.scala:362)
at
org.apache.spark.rdd.PairRDDFunctions.saveAsNewAPIHadoopDataset(PairRDDFunctions.scala:1084)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopFile$2.apply$mcV$sp(PairRDDFunctions.scala:1003)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopFile$2.apply(PairRDDFunctions.scala:994)
at
org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsNewAPIHadoopFile$2.apply(PairRDDFunctions.scala:994)
at
org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at
org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:112)
at org.apache.spark.rdd.RDD.withScope(RDD.scala:362)
at
org.apache.spark.rdd.PairRDDFunctions.saveAsNewAPIHadoopFile(PairRDDFunctions.scala:994)
at
org.apache.phoenix.spark.DataFrameFunctions.saveToPhoenix(DataFrameFunctions.scala:59)
at
org.apache.phoenix.spark.DataFrameFunctions.saveToPhoenix(DataFrameFunctions.scala:28)
at
org.apache.phoenix.spark.DefaultSource.createRelation(DefaultSource.scala:47)
at
org.apache.spark.sql.execution.datasources.DataSource.write(DataSource.scala:472)
at
org.apache.spark.sql.execution.datasources.SaveIntoDataSourceCommand.run(SaveIntoDataSourceCommand.scala:48)
at
org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult$lzycompute(commands.scala:58)
at
org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult(commands.scala:56)
at
org.apache.spark.sql.execution.command.ExecutedCommandExec.doExecute(commands.scala:74)
at
org.apache.spark.sql.execution.SparkPlan$$anonfun$execute$1.apply(SparkPlan.scala:117)
at
org.apache.spark.sql.execution.SparkPlan$$anonfun$execute$1.apply(SparkPlan.scala:117)
at
org.apache.spark.sql.execution.SparkPlan$$anonfun$executeQuery$1.apply(SparkPlan.scala:138)
at
org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at
org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:135)
at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:116)
at
org.apache.spark.sql.execution.QueryExecution.toRdd$lzycompute(QueryExecution.scala:92)
at
org.apache.spark.sql.execution.QueryExecution.toRdd(QueryExecution.scala:92)
at
org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:610)
at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:233)
[jira] [Commented] (PHOENIX-153) Implement TABLESAMPLE clause
[
https://issues.apache.org/jira/browse/PHOENIX-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109342#comment-16109342
]
ASF GitHub Bot commented on PHOENIX-153:
Github user aertoria commented on the issue:
https://github.com/apache/phoenix/pull/262
Commit 0507d4f change list:
1, explain plan a new way (Thanks for the suggestion)
2, squash previous four commit into one
3, revise all commit message to start with PHOENIX-153+space
preview on a Single select
`CLIENT 3-CHUNK 30 ROWS 2370 BYTES PARALLEL 1-WAY 0.2-SAMPLED ROUND ROBIN
FULL SCAN OVER PERSON`
on a Join select
```
CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY 0.65-SAMPLED ROUND ROBIN FULL
SCAN OVER INX_ADDRESS_PERSON
SERVER FILTER BY FIRST KEY ONLY
PARALLEL INNER-JOIN TABLE 0
CLIENT 1-CHUNK 1 ROWS 32 BYTES PARALLEL 1-WAY 0.15-SAMPLED ROUND
ROBIN FULL SCAN OVER US_POPULATION
DYNAMIC SERVER FILTER BY TO_CHAR("INX_ADDRESS_PERSON.0:ADDRESS") IN
(US_POPULATION.STATE)
```
> Implement TABLESAMPLE clause
>
>
> Key: PHOENIX-153
> URL: https://issues.apache.org/jira/browse/PHOENIX-153
> Project: Phoenix
> Issue Type: Task
>Reporter: James Taylor
>Assignee: Ethan Wang
> Labels: enhancement
> Attachments: Sampling_Accuracy_Performance.jpg
>
>
> Support the standard SQL TABLESAMPLE clause by implementing a filter that
> uses a skip next hint based on the region boundaries of the table to only
> return n rows per region.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix issue #262: PHOENIX 153 implement TABLESAMPLE clause
Github user aertoria commented on the issue:
https://github.com/apache/phoenix/pull/262
Commit 0507d4f change list:
1, explain plan a new way (Thanks for the suggestion)
2, squash previous four commit into one
3, revise all commit message to start with PHOENIX-153+space
preview on a Single select
`CLIENT 3-CHUNK 30 ROWS 2370 BYTES PARALLEL 1-WAY 0.2-SAMPLED ROUND ROBIN
FULL SCAN OVER PERSON`
on a Join select
```
CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY 0.65-SAMPLED ROUND ROBIN FULL
SCAN OVER INX_ADDRESS_PERSON
SERVER FILTER BY FIRST KEY ONLY
PARALLEL INNER-JOIN TABLE 0
CLIENT 1-CHUNK 1 ROWS 32 BYTES PARALLEL 1-WAY 0.15-SAMPLED ROUND
ROBIN FULL SCAN OVER US_POPULATION
DYNAMIC SERVER FILTER BY TO_CHAR("INX_ADDRESS_PERSON.0:ADDRESS") IN
(US_POPULATION.STATE)
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (PHOENIX-4022) Add PhoenixMetricsLog interface that can be used to log metrics for queries and mutations.
[ https://issues.apache.org/jira/browse/PHOENIX-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108769#comment-16108769 ] Hudson commented on PHOENIX-4022: - FAILURE: Integrated in Jenkins build Phoenix-master #1724 (See [https://builds.apache.org/job/Phoenix-master/1724/]) PHOENIX-4022 Add PhoenixMetricsLog interface that can be used to log (thomas: rev 534fa05dad66cc8aedfcbc6622bfbbd8ed714b73) * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/DelegatePreparedStatement.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/trace/DelegateConnection.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/LoggingPhoenixPreparedStatement.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/LoggingPhoenixStatement.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/LoggingPhoenixResultSet.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/LoggingPhoenixConnection.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixMetricsLog.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/DelegateStatement.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/trace/BaseTracingTestIT.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/DelegateConnection.java * (add) phoenix-core/src/main/java/org/apache/phoenix/jdbc/DelegateResultSet.java > Add PhoenixMetricsLog interface that can be used to log metrics for queries > and mutations. > --- > > Key: PHOENIX-4022 > URL: https://issues.apache.org/jira/browse/PHOENIX-4022 > Project: Phoenix > Issue Type: New Feature >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.12.0 > > Attachments: PHOENIX-4022.patch, PHOENIX-4022-v2.patch, > PHOENIX-4022-v3.patch, PHOENIX-4022-v4.patch > > > Create a wrapper for PhoenixConnection, PhoenixStatement, > PhoenixPreparedStatement and PhoenixResultSet that automatically calls the > PhoenixMetricsLog logging methods so users don't have to instrument this > themselves. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
