[jira] [Updated] (PHOENIX-3073) Fast path for single-key point lookups

[Junegunn Choi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Junegunn Choi updated PHOENIX-3073:
---
Summary: Fast path for single-key point lookups  (was: Auto-detect when 
SMALL hint should be applied)

> Fast path for single-key point lookups
> --
>
> Key: PHOENIX-3073
> URL: https://issues.apache.org/jira/browse/PHOENIX-3073
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Junegunn Choi
> Fix For: 4.12.0
>
> Attachments: 3073-try.txt, PHOENIX-3073.patch
>
>
> While comparing Phoenix JDBC client to the native HBase Java client, I 
> noticed that Phoenix client uses significantly more CPU time on the client 
> machine. Profiling revealed that the majority of the time was spent on 
> {{BaseResultIterators.getParallelScans()}}. This was surprising to me as I 
> was only testing with simple point lookup queries.
> Here's how I tested:
> - {{SELECT /*+ SMALL SERIAL */ ID, DOCID FROM IMAGE WHERE ID = ?}}
> - {{IMAGE}} is a salted table with 100 salt buckets
> - {{ID}}, the primary key, was randomly selected in a small range so that 
> the requests are served without disk I/O
> - 20K/sec concurrent requests using 128 threads
> {{getParallelScans()}} is quite expensive as it iterates over all regions of 
> the table which can be many, only to return a single Scan object for this 
> query. Since such a single-key point lookup is one of the most frequent type 
> of requests in a typical OLTP application, I believe it makes sense to have a 
> fast path for it. With the patch, the average CPU usage of the client during 
> the workload dropped to 18.8% from 56.7% before the patch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3073) Auto-detect when SMALL hint should be applied

[Junegunn Choi (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051406#comment-16051406
 ] 

Junegunn Choi commented on PHOENIX-3073:


I haven't looked into this for a while, but I noticed that it was renamed and 
the new title does not match the original intention, let me rename it again for 
future reference. And I don't think it's related to PHOENIX-1267.

> Auto-detect when SMALL hint should be applied
> -
>
> Key: PHOENIX-3073
> URL: https://issues.apache.org/jira/browse/PHOENIX-3073
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Junegunn Choi
> Fix For: 4.12.0
>
> Attachments: 3073-try.txt, PHOENIX-3073.patch
>
>
> While comparing Phoenix JDBC client to the native HBase Java client, I 
> noticed that Phoenix client uses significantly more CPU time on the client 
> machine. Profiling revealed that the majority of the time was spent on 
> {{BaseResultIterators.getParallelScans()}}. This was surprising to me as I 
> was only testing with simple point lookup queries.
> Here's how I tested:
> - {{SELECT /*+ SMALL SERIAL */ ID, DOCID FROM IMAGE WHERE ID = ?}}
> - {{IMAGE}} is a salted table with 100 salt buckets
> - {{ID}}, the primary key, was randomly selected in a small range so that 
> the requests are served without disk I/O
> - 20K/sec concurrent requests using 128 threads
> {{getParallelScans()}} is quite expensive as it iterates over all regions of 
> the table which can be many, only to return a single Scan object for this 
> query. Since such a single-key point lookup is one of the most frequent type 
> of requests in a typical OLTP application, I believe it makes sense to have a 
> fast path for it. With the patch, the average CPU usage of the client during 
> the workload dropped to 18.8% from 56.7% before the patch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Simple and complex views

[Julian Hyde]

I was speaking with Rajesh and Ankit at DataWorks Summit today and they said 
that Phoenix views have to be “simple”, that is, made up of only SELECT … WHERE.

Is that the case? If so, are there any plans to lift the restriction, and allow 
views with, say, JOIN, UNION and GROUP BY?

The more complex views would not allow inserts/upserts/deletes, because a 
single row in the view would not necessarily correspond to a single row in the 
underlying table, but nevertheless, complex views are extremely useful for 
read-only queries. Calcite allows view expansion for complex views, and even 
for views upon views, so it should be straightforward to do in 5.0.

Julian

[jira] [Commented] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051348#comment-16051348
 ] 

Hadoop QA commented on PHOENIX-3940:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12873200/PHOENIX-3940.002.patch
  against master branch at commit 7e49d80d08299136cbbaa46be113724961f74c72.
  ATTACHMENT ID: 12873200

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
50 warning messages.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.MutableRollbackIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.RollbackIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.UpdateCacheIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.UpdateCacheAcrossDifferentClientsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TransactionIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1107//testReport/
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1107//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1107//console

This message is automatically generated.

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch, PHOENIX-3940.002.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (PHOENIX-3863) Document DAYOFWEEK, DAYOFYEAR, and any other missing functions

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor resolved PHOENIX-3863.
---
Resolution: Fixed

Thanks, [~pconrad] - I've checked in your doc fix. 

> Document DAYOFWEEK, DAYOFYEAR, and any other missing functions
> --
>
> Key: PHOENIX-3863
> URL: https://issues.apache.org/jira/browse/PHOENIX-3863
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Peter Conrad
> Attachments: dayofweekandyear.diff
>
>
> Looks like the above functions committed in PHOENIX-3201 were never 
> documented here: https://phoenix.apache.org/language/functions.html. We 
> should check if there are others too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Samarth Jain (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051246#comment-16051246
 ] 

Samarth Jain commented on PHOENIX-3942:
---

[~karanmehta93], can you provide me patches for the master and 4.x-HBase-1.2 
branches too. Keep in mind to not remove the two metrics on these two branches. 
Thanks!

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch, 
> PHOENIX-3942.4.x-HBase-1.1.002.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3951) Add explicit instructions and example on how to disable column encoding

[James Taylor (JIRA)]

James Taylor created PHOENIX-3951:
-

 Summary: Add explicit instructions and example on how to disable 
column encoding
 Key: PHOENIX-3951
 URL: https://issues.apache.org/jira/browse/PHOENIX-3951
 Project: Phoenix
  Issue Type: Task
Reporter: James Taylor
Assignee: Samarth Jain


It's come up a number of times on the mailing list. Can we add explicit 
instructions and an example on how to turn off column encoding here: 
https://phoenix.apache.org/columnencoding.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[James Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051243#comment-16051243
 ] 

James Taylor commented on PHOENIX-3940:
---

+1. Thanks, [~elserj]!

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch, PHOENIX-3940.002.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[Josh Elser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated PHOENIX-3940:

Attachment: PHOENIX-3940.002.patch

.002 implements James' suggestion

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch, PHOENIX-3940.002.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051238#comment-16051238
 ] 

Josh Elser commented on PHOENIX-3940:
-

Thanks James! I was hoping you'd see my patch and bestow some knowledge on me ;)

Will put a v2 up shortly.

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3950) IndexTool marks index active even when index building fails

[James Taylor (JIRA)]

James Taylor created PHOENIX-3950:
-

 Summary: IndexTool marks index active even when index building 
fails
 Key: PHOENIX-3950
 URL: https://issues.apache.org/jira/browse/PHOENIX-3950
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


We've seen cases in which the MR-based index building tool (IndexTool) marks an 
index as active when the index building clearly did not succeed. It might be 
related to a timeout occurring and then not being propagated to the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3947) Increase scan time out for partial index rebuild

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3947:
--
Labels: indexImprovement  (was: partialIndexRebuild)

> Increase scan time out for partial index rebuild
> 
>
> Key: PHOENIX-3947
> URL: https://issues.apache.org/jira/browse/PHOENIX-3947
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>  Labels: indexImprovement
>
> The scan done from MetaDataRegionObserver needs to have a higher timeout so 
> that it can always complete successfully. If it times out, it'll start over 
> again which is not great.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3947) Increase scan time out for partial index rebuild

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3947:
--
Summary: Increase scan time out for partial index rebuild  (was: Time out 
should be higher for partial index rebuild)

> Increase scan time out for partial index rebuild
> 
>
> Key: PHOENIX-3947
> URL: https://issues.apache.org/jira/browse/PHOENIX-3947
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>  Labels: partialIndexRebuild
>
> The scan done from MetaDataRegionObserver needs to have a higher timeout so 
> that it can always complete successfully. If it times out, it'll start over 
> again which is not great.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3949) Stop index maintenance until INDEX_DISABLED_TIMESTAMP is cleared

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3949:
--
Summary: Stop index maintenance until INDEX_DISABLED_TIMESTAMP is cleared  
(was: Stop index writing until index_disable_timestamp is cleared)

> Stop index maintenance until INDEX_DISABLED_TIMESTAMP is cleared
> 
>
> Key: PHOENIX-3949
> URL: https://issues.apache.org/jira/browse/PHOENIX-3949
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>  Labels: indexImprovement
>
> An index can be configured to remain online if a write failure occurs as our 
> partial index rebuilder will kick in upon failure and catch it up. However, 
> by keeping the index active, subsequent writes to the data table will likely 
> time out when they attempt to update the index given the current timeouts 
> (see PHOENIX-3948).
> An alternative would be to hold off on any index updates until the partial 
> index rebuilder has completed the catch up process and cleared the 
> INDEX_DISABLED_TIMESTAMP field. This creates a race condition with writes 
> that happen right as the INDEX_DISABLED_TIMESTAMP field is cleared. We could 
> run a catchup query on the partial index rebuild after the field is cleared 
> to ensure we find rows that were committed before the regular index 
> maintenance starts again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3949) Stop index writing until index_disable_timestamp is cleared

[James Taylor (JIRA)]

James Taylor created PHOENIX-3949:
-

 Summary: Stop index writing until index_disable_timestamp is 
cleared
 Key: PHOENIX-3949
 URL: https://issues.apache.org/jira/browse/PHOENIX-3949
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


An index can be configured to remain online if a write failure occurs as our 
partial index rebuilder will kick in upon failure and catch it up. However, by 
keeping the index active, subsequent writes to the data table will likely time 
out when they attempt to update the index given the current timeouts (see 
PHOENIX-3948).

An alternative would be to hold off on any index updates until the partial 
index rebuilder has completed the catch up process and cleared the 
INDEX_DISABLED_TIMESTAMP field. This creates a race condition with writes that 
happen right as the INDEX_DISABLED_TIMESTAMP field is cleared. We could run a 
catchup query on the partial index rebuild after the field is cleared to ensure 
we find rows that were committed before the regular index maintenance starts 
again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release of Apache Phoenix 4.11.0 RC1

[Josh Elser]

+1 (binding)

* xsums/sigs OK
* Verified pom.xml made no changes (implying no required L changes)
* apache-rat:check on all src archives
* Can build from source on all archives
* Ran all UT/IT successfully on hbase-1.3 release

- Josh

On 6/14/17 4:57 PM, James Taylor wrote:

Hello Everyone,

This is a call for a vote on Apache Phoenix 4.11.0 RC1. This is the next
minor release of Phoenix 4, compatible with Apache HBase 0.98, 1.1, 1.2, &
1.3. The release includes both a source-only release and a convenience
binary release for each supported HBase version. The previous RC was sunk
due to PHOENIX-3890 which has now been fixed.

This release has feature parity with supported HBase versions and includes
the following improvements:
- Support for HBase 1.3.1+
- Atomic update of data and local index rows (HBase 1.3 only) [1]
- Local index hardening and performance improvements [2]
- Use HBase snapshots for MR-based queries and async index building [3][4]
- Support for forward-only cursors [5]
- Ensure chunking of commit data uses byte-based and row-count limits [6]
- Reduce load on SYSTEM.CATALOG region server [7]
- Implement FIRST_VALUES and LAST_VALUES aggregate functions [8]
- 50+ bug fixes

The source tarball, including signatures, digests, etc can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-0.98-rc1/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.1-rc1/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.2-rc1/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.3-rc1/src/

The binary artifacts can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-0.98-rc1/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.1-rc1/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.2-rc1/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.11.0-HBase-1.3-rc1/bin/

For a complete list of changes, see:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12339764

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/mujtaba.asc
https://dist.apache.org/repos/dist/release/phoenix/KEYS

The hash and tag to be voted upon:
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=4bc09b8167c9a9f8af205eb19f25e0687527d3c4
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.11.0-HBase-0.98-rc1
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=78a41484f583aa35285b5a8a8d82714458a9e8da
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.11.0-HBase-1.1-rc1
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=d70dab9c134cdefb7c5771023d1f774ee601455a
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.11.0-HBase-1.2-rc1
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=de6fbc4e2a13cdc482cbc1c91e51c4bc526aa12f
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.11.0-HBase-1.3-rc1

Vote will be open for at least 72 hours. Please vote:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
The Apache Phoenix Team

[1] https://issues.apache.org/jira/browse/PHOENIX-3827
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20and%20fixVersion%3D4.11.0%20and%20labels%3DlocalIndex
[3] https://issues.apache.org/jira/browse/PHOENIX-3744
[4] https://issues.apache.org/jira/browse/PHOENIX-3812
[5] https://issues.apache.org/jira/browse/PHOENIX-3572
[6] https://issues.apache.org/jira/browse/PHOENIX-3784
[7] https://issues.apache.org/jira/browse/PHOENIX-3819
[8] https://issues.apache.org/jira/browse/PHOENIX-3773

[jira] [Commented] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Josh Mahonin (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051228#comment-16051228
 ] 

Josh Mahonin commented on PHOENIX-3946:
---

We bumped the default Spark version already to 2.0.2 as part of PHOENIX-
https://github.com/apache/phoenix/commit/a0e5efcec5a1a732b2dce9794251242c3d66eea6

Investigating moving to Spark 2.1.1 is a worthwhile endeavour though, hopefully 
they haven't broken the API layer (again) :)



> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
>Assignee: Kanagha Pradha
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan] [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Samarth Jain (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051222#comment-16051222
 ] 

Samarth Jain commented on PHOENIX-3942:
---

Patch looks good, [~karanmehta93]. +1

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch, 
> PHOENIX-3942.4.x-HBase-1.1.002.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3948) Enable shorter time outs for server-side index writes

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3948:
--
Labels: indexImprovement  (was: )

> Enable shorter time outs for server-side index writes
> -
>
> Key: PHOENIX-3948
> URL: https://issues.apache.org/jira/browse/PHOENIX-3948
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>  Labels: indexImprovement
>
> The default timeouts are far too high for a RS->RS global index update as 
> we're holding on to a handler thread when the retries occur. We should be 
> able to set them to be inline with the client-side timeouts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3948) Enable shorter time outs for server-side index writes

[James Taylor (JIRA)]

James Taylor created PHOENIX-3948:
-

 Summary: Enable shorter time outs for server-side index writes
 Key: PHOENIX-3948
 URL: https://issues.apache.org/jira/browse/PHOENIX-3948
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


The default timeouts are far too high for a RS->RS global index update as we're 
holding on to a handler thread when the retries occur. We should be able to set 
them to be inline with the client-side timeouts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3947) Time out should be higher for partial index rebuild

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3947:
--
Labels: partialIndexRebuild  (was: )

> Time out should be higher for partial index rebuild
> ---
>
> Key: PHOENIX-3947
> URL: https://issues.apache.org/jira/browse/PHOENIX-3947
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>  Labels: partialIndexRebuild
>
> The scan done from MetaDataRegionObserver needs to have a higher timeout so 
> that it can always complete successfully. If it times out, it'll start over 
> again which is not great.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3947) Time out should be higher for partial index rebuild

[James Taylor (JIRA)]

James Taylor created PHOENIX-3947:
-

 Summary: Time out should be higher for partial index rebuild
 Key: PHOENIX-3947
 URL: https://issues.apache.org/jira/browse/PHOENIX-3947
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


The scan done from MetaDataRegionObserver needs to have a higher timeout so 
that it can always complete successfully. If it times out, it'll start over 
again which is not great.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-3946:
--
Fix Version/s: (was: 4.10.0)

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
>Assignee: Kanagha Pradha
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan] [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[James Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor reassigned PHOENIX-3946:
-

Assignee: Kanagha Pradha

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
>Assignee: Kanagha Pradha
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan] [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Kanagha Pradha (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051198#comment-16051198
 ] 

Kanagha Pradha commented on PHOENIX-3946:
-

[~jamestaylor], Could you please assign this to me? Thanks


> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan] [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Kanagha Pradha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kanagha Pradha updated PHOENIX-3946:

Description: 
Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
It is already set up to use scala 2.10 version.

[~mujtabachohan] [~jamestaylor]

  was:
Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
It is already set up to use scala 2.10 version.

[~mujtabachohan]


> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan] [~jamestaylor]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Zach York (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051176#comment-16051176
 ] 

Zach York commented on PHOENIX-3946:


Also probably a separate JIRA, but should scala 2.11 be supported as well?

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Zach York (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051175#comment-16051175
 ] 

Zach York commented on PHOENIX-3946:


Why not move up to the latest version of spark? Spark 2.1.1

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Mujtaba Chohan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mujtaba Chohan reassigned PHOENIX-3946:
---

Assignee: (was: Mujtaba Chohan)

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Mujtaba Chohan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mujtaba Chohan reassigned PHOENIX-3946:
---

Assignee: Mujtaba Chohan

> Update phoenix-spark to use 2.0.2 version
> -
>
> Key: PHOENIX-3946
> URL: https://issues.apache.org/jira/browse/PHOENIX-3946
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 4.10.0
>Reporter: Kanagha Pradha
>Assignee: Mujtaba Chohan
> Fix For: 4.10.0
>
>
> Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
> It is already set up to use scala 2.10 version.
> [~mujtabachohan]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Karan Mehta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karan Mehta updated PHOENIX-3942:
-
Attachment: PHOENIX-3942.4.x-HBase-1.1.002.patch

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch, 
> PHOENIX-3942.4.x-HBase-1.1.002.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[James Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051146#comment-16051146
 ] 

James Taylor commented on PHOENIX-3940:
---

Thanks for the patch, [~elserj]. I'd recommend setting ptr to an empty byte 
array and returning true. The client-side aggregators would always return true. 
 Something like this:
{code}
 double result = 0.0;
 Number n1 = (Number)o1;
-if (o2 == null || o1 == o2) {
+if (o1 == null && o2 == null) {
+ptr.set(ByteUtil.EMPTY_BYTE_ARRAY);
+return true;
+} else if (o2 == null || o1 == o2) {
 result = n1.doubleValue();
 } else {
 Number n2 = (Number)o2;
{code}
Longer explanation of returning true versus false here: 
https://issues.apache.org/jira/browse/PHOENIX-3918?focusedCommentId=16043672=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16043672.
 Since there aren't any child expressions for client-side aggregators and we 
essentially have all the information we'll ever have from the server, we can 
always calculate a value (which might be null), so we always return true.

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3654) Load Balancer for thin client

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051135#comment-16051135
 ] 

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_r122323098
  
--- Diff: 
phoenix-queryserver/src/main/java/org/apache/phoenix/queryserver/server/QueryServer.java
 ---
@@ -233,16 +240,29 @@ public int run(String[] args) throws Exception {
   // Build and start the HttpServer
   server = builder.build();
   server.start();
+  registerToServiceProvider(hostname);
   runningLatch.countDown();
   server.join();
   return 0;
 } catch (Throwable t) {
   LOG.fatal("Unrecoverable service error. Shutting down.", t);
   this.t = t;
   return -1;
+} finally {
+  deRegister();
 }
   }
 
+  private void registerToServiceProvider(String hostName) throws Exception 
{
+  PqsZookeeperConf pqsZookeeperConf = new 
PqsZookeeperConfImpl(getConf());
--- End diff --

Here's an example from Avatica on how it uses ServiceLoader to pull Metrics 
backend systems:

A [factory interface is defined in one 
module](https://github.com/apache/calcite-avatica/blob/master/metrics/src/main/java/org/apache/calcite/avatica/metrics/MetricsSystemFactory.java),
 an [implementation is defined in a different 
module](https://github.com/apache/calcite-avatica/blob/master/metrics-dropwizardmetrics3/src/main/java/org/apache/calcite/avatica/metrics/dropwizard3/DropwizardMetricsSystemFactory.java),
 a [services file is created stating that the implementation is present for the 
interface](https://github.com/apache/calcite-avatica/blob/master/metrics-dropwizardmetrics3/src/main/resources/META-INF/services/org.apache.calcite.avatica.metrics.MetricsSystemFactory),
 the Avatica server [loads an implementation of the interface using 
ServiceLoader](https://github.com/apache/calcite-avatica/blob/master/server/src/main/java/org/apache/calcite/avatica/server/HandlerFactory.java#L114)


> 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
> Fix For: 4.9.0
>
> 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

[joshelser]

Github user joshelser commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/236#discussion_r122323098
  
--- Diff: 
phoenix-queryserver/src/main/java/org/apache/phoenix/queryserver/server/QueryServer.java
 ---
@@ -233,16 +240,29 @@ public int run(String[] args) throws Exception {
   // Build and start the HttpServer
   server = builder.build();
   server.start();
+  registerToServiceProvider(hostname);
   runningLatch.countDown();
   server.join();
   return 0;
 } catch (Throwable t) {
   LOG.fatal("Unrecoverable service error. Shutting down.", t);
   this.t = t;
   return -1;
+} finally {
+  deRegister();
 }
   }
 
+  private void registerToServiceProvider(String hostName) throws Exception 
{
+  PqsZookeeperConf pqsZookeeperConf = new 
PqsZookeeperConfImpl(getConf());
--- End diff --

Here's an example from Avatica on how it uses ServiceLoader to pull Metrics 
backend systems:

A [factory interface is defined in one 
module](https://github.com/apache/calcite-avatica/blob/master/metrics/src/main/java/org/apache/calcite/avatica/metrics/MetricsSystemFactory.java),
 an [implementation is defined in a different 
module](https://github.com/apache/calcite-avatica/blob/master/metrics-dropwizardmetrics3/src/main/java/org/apache/calcite/avatica/metrics/dropwizard3/DropwizardMetricsSystemFactory.java),
 a [services file is created stating that the implementation is present for the 
interface](https://github.com/apache/calcite-avatica/blob/master/metrics-dropwizardmetrics3/src/main/resources/META-INF/services/org.apache.calcite.avatica.metrics.MetricsSystemFactory),
 the Avatica server [loads an implementation of the interface using 
ServiceLoader](https://github.com/apache/calcite-avatica/blob/master/server/src/main/java/org/apache/calcite/avatica/server/HandlerFactory.java#L114)


---
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] [Created] (PHOENIX-3946) Update phoenix-spark to use 2.0.2 version

[Kanagha Pradha (JIRA)]

Kanagha Pradha created PHOENIX-3946:
---

 Summary: Update phoenix-spark to use 2.0.2 version
 Key: PHOENIX-3946
 URL: https://issues.apache.org/jira/browse/PHOENIX-3946
 Project: Phoenix
  Issue Type: Task
Affects Versions: 4.10.0
Reporter: Kanagha Pradha
 Fix For: 4.10.0


Phoenix uses spark 1.6.1 currently. This needs to be updated to 2.0.2 version.
It is already set up to use scala 2.10 version.

[~mujtabachohan]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051093#comment-16051093
 ] 

Hadoop QA commented on PHOENIX-3942:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12873174/PHOENIX-3942.4.x-HBase-1.1.001.patch
  against 4.x-HBase-1.1 branch at commit 
de6fbc4e2a13cdc482cbc1c91e51c4bc526aa12f.
  ATTACHMENT ID: 12873174

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
50 warning messages.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.IndexExtendedIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1100//testReport/
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1100//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1100//console

This message is automatically generated.

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3940) NullPointerException on PERCENTILE_CONT over an empty result set

[Josh Elser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated PHOENIX-3940:

Attachment: PHOENIX-3940.001.patch

.001 Adds a test for both of the values being null. Added IT which breaks 
before the fix.

I'm not sure if {{return false}} (which causes the client to see a {{null}} 
value) is the proper action or not. I would welcome any opinions :)

> NullPointerException on PERCENTILE_CONT over an empty result set
> 
>
> Key: PHOENIX-3940
> URL: https://issues.apache.org/jira/browse/PHOENIX-3940
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3940.001.patch
>
>
> A user reported that when running a query with {{PERCENTILE_CONT}} where the 
> selection has no results (e.g. nothing to compute the P_C on), a 
> NullPointerException is thrown.
> Glancing at the code, it can handle the case where there is only one value, 
> but handling the case where there are no values fails.
> Reading over Oracle and SqlServer docs, it doesn't saw what "should" happen 
> in these cases. Is "0" a sane value? Or is an exception actually a good idea?
> https://docs.microsoft.com/en-us/sql/t-sql/functions/percentile-cont-transact-sql
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions115.htm#SQLRF00687



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Karan Mehta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karan Mehta updated PHOENIX-3942:
-
Attachment: PHOENIX-3942.4.x-HBase-1.1.001.patch

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Karan Mehta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karan Mehta updated PHOENIX-3942:
-
Attachment: (was: PHOENIX-3942.4.x-HBase-1.1.001.patch)

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Karan Mehta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karan Mehta updated PHOENIX-3942:
-
Attachment: PHOENIX-3942.4.x-HBase-1.1.001.patch

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
> Attachments: PHOENIX-3942.4.x-HBase-1.1.001.patch
>
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3942) Fix failing PhoenixMetricsIT test

[Karan Mehta (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050920#comment-16050920
 ] 

Karan Mehta commented on PHOENIX-3942:
--

[~jamestaylor]
HBase 1.1 didn't have {{ServerSideScanMetrics}} class which contains the 
metrics {{ROWS_SCANNED}} and {{ROWS_FILTERED}}. It was introduced in 1.2. This 
is the reason for NPE when accessing those metrics from the {{ScanMetrics}} map 
returned by the server. 
The fix would be as follows
{code}
-static final String COUNT_OF_ROWS_FILTERED_KEY_METRIC_NAME = 
"ROWS_FILTERED";
-static final String GLOBAL_BYTES_IN_RESULTS_METRIC_NAME = 
"BYTES_IN_RESULTS";
-
scanMetricsHolder.getCountOfRowsScanned().change(scanMetricsMap.get(COUNT_OF_ROWS_SCANNED_KEY_METRIC_NAME));
-
scanMetricsHolder.getCountOfRowsFiltered().change(scanMetricsMap.get(COUNT_OF_ROWS_FILTERED_KEY_METRIC_NAME));
{code}

Will submit a patch soon for this branch.

> Fix failing PhoenixMetricsIT test
> -
>
> Key: PHOENIX-3942
> URL: https://issues.apache.org/jira/browse/PHOENIX-3942
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Karan Mehta
>
> The PhoenixMetricsIT seems to be consistently failing in setup with the 
> following exception:
> {code}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 
> s <<< FAILURE! - in org.apache.phoenix.monitoring.PhoenixMetricsIT
> [ERROR] org.apache.phoenix.monitoring.PhoenixMetricsIT  Time elapsed: 0.025 s 
>  <<< ERROR!
> org.apache.phoenix.exception.PhoenixIOException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.phoenix.monitoring.PhoenixMetricsIT.doSetup(PhoenixMetricsIT.java:95)
> Caused by: java.lang.NullPointerException
> {code}
> See 
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/436/display/redirect?page=changes
>  for more information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3929) Update website with recently added features FIRST_VALUES and LAST_VALUES

[Thomas D'Silva (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050845#comment-16050845
 ] 

Thomas D'Silva commented on PHOENIX-3929:
-

[~singamteja]

Sure, will commit this after 4.11 is released.

> Update website with recently added features FIRST_VALUES and LAST_VALUES
> 
>
> Key: PHOENIX-3929
> URL: https://issues.apache.org/jira/browse/PHOENIX-3929
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Loknath Priyatham Teja Singamsetty 
>Assignee: Loknath Priyatham Teja Singamsetty 
>Priority: Trivial
> Fix For: 4.11.0, 4.12.0
>
> Attachments: website_update.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string

[Shehzaad Nakhoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050515#comment-16050515
 ] 

Shehzaad Nakhoda commented on PHOENIX-3945:
---

[~jamestaylor] Here's the JIRA we discussed.

> Introduce new Scalar Function to calculate a collation key from a string
> 
>
> Key: PHOENIX-3945
> URL: https://issues.apache.org/jira/browse/PHOENIX-3945
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Shehzaad Nakhoda
>
> It is necessary to do sort varchars in a language-sensitive way.
> A scalar function is needed which given a string and a locale should return a 
> byte array that can then be sorted in binary order.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (PHOENIX-3945) Introduce new Scalar Function to calculate a collation key from a string

[Shehzaad Nakhoda (JIRA)]

Shehzaad Nakhoda created PHOENIX-3945:
-

 Summary: Introduce new Scalar Function to calculate a collation 
key from a string
 Key: PHOENIX-3945
 URL: https://issues.apache.org/jira/browse/PHOENIX-3945
 Project: Phoenix
  Issue Type: New Feature
Reporter: Shehzaad Nakhoda


It is necessary to do sort varchars in a language-sensitive way.

A scalar function is needed which given a string and a locale should return a 
byte array that can then be sorted in binary order.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (PHOENIX-3944) ReadOnlyTableException occurs when we map Phoenix view to an existing HBase table with Namespace Mapping enabled

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050284#comment-16050284
 ] 

ASF GitHub Bot commented on PHOENIX-3944:
-

Github user brfrn169 commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/261#discussion_r122169866
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -196,7 +196,8 @@ public static ColumnResolver 
getResolverForCreation(final CreateTableStatement s
 if (htable != null) Closeables.closeQuietly(htable);
 }
 tableNode = NamedTableNode.create(null, baseTable, 
statement.getColumnDefs());
-return new SingleTableColumnResolver(connection, 
tableNode, e.getTimeStamp(), new HashMap(1), false);
+boolean isNamespaceMapped = 
SchemaUtil.isNamespaceMappingEnabled(statement.getTableType(), 
connection.getQueryServices().getProps());
--- End diff --

Originally the SingleTableColumnResolver constructor argument 
"isNamespaceMapped" is hard-coded as false, but we should set it from props.


> ReadOnlyTableException occurs when we map Phoenix view to an existing HBase 
> table with Namespace Mapping enabled
> 
>
> Key: PHOENIX-3944
> URL: https://issues.apache.org/jira/browse/PHOENIX-3944
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>
> Firstly, I created a namespace and a table in hbase shell:
> {code}
> hbase> create_namespace "NS"
> hbase> create "NS:TBL", "CF"
> {code}
> After that, I tried to create a phoenix view for this existing hbase table in 
> phoenix-sqlline:
> {code}
> phoenix> CREATE VIEW ns.tbl (pk VARCHAR PRIMARY KEY, cf.col VARCHAR);
> {code}
> However, I encountered the following error and I was not able to create the 
> view:
> {code}
> org.apache.phoenix.schema.ReadOnlyTableException: ERROR 505 (42000): Table is 
> read only.
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:1072)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1434)
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:2624)
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1040)
>   at 
> org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:212)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:393)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:375)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:363)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1707)
>   at org.apache.PhoenixTest.main(PhoenixTest.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] phoenix pull request #261: PHOENIX-3944 ReadOnlyTableException occurs when w...

[brfrn169]

Github user brfrn169 commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/261#discussion_r122169866
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -196,7 +196,8 @@ public static ColumnResolver 
getResolverForCreation(final CreateTableStatement s
 if (htable != null) Closeables.closeQuietly(htable);
 }
 tableNode = NamedTableNode.create(null, baseTable, 
statement.getColumnDefs());
-return new SingleTableColumnResolver(connection, 
tableNode, e.getTimeStamp(), new HashMap(1), false);
+boolean isNamespaceMapped = 
SchemaUtil.isNamespaceMappingEnabled(statement.getTableType(), 
connection.getQueryServices().getProps());
--- End diff --

Originally the SingleTableColumnResolver constructor argument 
"isNamespaceMapped" is hard-coded as false, but we should set it from props.


---
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-3944) ReadOnlyTableException occurs when we map Phoenix view to an existing HBase table with Namespace Mapping enabled

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050268#comment-16050268
 ] 

ASF GitHub Bot commented on PHOENIX-3944:
-

GitHub user brfrn169 opened a pull request:

https://github.com/apache/phoenix/pull/261

PHOENIX-3944 ReadOnlyTableException occurs when we map Phoenix view t…

…o an existing HBase table with Namespace Mapping enabled



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brfrn169/phoenix PHOENIX-3944

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/261.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 #261


commit 90debc2d343660e68dbb5d43ca2d6c7f4c69958c
Author: Toshihiro Suzuki 
Date:   2017-06-15T09:54:44Z

PHOENIX-3944 ReadOnlyTableException occurs when we map Phoenix view to an 
existing HBase table with Namespace Mapping enabled




> ReadOnlyTableException occurs when we map Phoenix view to an existing HBase 
> table with Namespace Mapping enabled
> 
>
> Key: PHOENIX-3944
> URL: https://issues.apache.org/jira/browse/PHOENIX-3944
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>
> Firstly, I created a namespace and a table in hbase shell:
> {code}
> hbase> create_namespace "NS"
> hbase> create "NS:TBL", "CF"
> {code}
> After that, I tried to create a phoenix view for this existing hbase table in 
> phoenix-sqlline:
> {code}
> phoenix> CREATE VIEW ns.tbl (pk VARCHAR PRIMARY KEY, cf.col VARCHAR);
> {code}
> However, I encountered the following error and I was not able to create the 
> view:
> {code}
> org.apache.phoenix.schema.ReadOnlyTableException: ERROR 505 (42000): Table is 
> read only.
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:1072)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1434)
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:2624)
>   at 
> org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1040)
>   at 
> org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:212)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:393)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:375)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:363)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1707)
>   at org.apache.PhoenixTest.main(PhoenixTest.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] phoenix pull request #261: PHOENIX-3944 ReadOnlyTableException occurs when w...

[brfrn169]

GitHub user brfrn169 opened a pull request:

https://github.com/apache/phoenix/pull/261

PHOENIX-3944 ReadOnlyTableException occurs when we map Phoenix view t…

…o an existing HBase table with Namespace Mapping enabled



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brfrn169/phoenix PHOENIX-3944

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/261.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 #261


commit 90debc2d343660e68dbb5d43ca2d6c7f4c69958c
Author: Toshihiro Suzuki 
Date:   2017-06-15T09:54:44Z

PHOENIX-3944 ReadOnlyTableException occurs when we map Phoenix view to an 
existing HBase table with Namespace Mapping enabled




---
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] [Created] (PHOENIX-3944) ReadOnlyTableException occurs when we map Phoenix view to an existing HBase table with Namespace Mapping enabled

[Toshihiro Suzuki (JIRA)]

Toshihiro Suzuki created PHOENIX-3944:
-

 Summary: ReadOnlyTableException occurs when we map Phoenix view to 
an existing HBase table with Namespace Mapping enabled
 Key: PHOENIX-3944
 URL: https://issues.apache.org/jira/browse/PHOENIX-3944
 Project: Phoenix
  Issue Type: Bug
Reporter: Toshihiro Suzuki


Firstly, I created a namespace and a table in hbase shell:
{code}
hbase> create_namespace "NS"
hbase> create "NS:TBL", "CF"
{code}

After that, I tried to create a phoenix view for this existing hbase table in 
phoenix-sqlline:
{code}
phoenix> CREATE VIEW ns.tbl (pk VARCHAR PRIMARY KEY, cf.col VARCHAR);
{code}

However, I encountered the following error and I was not able to create the 
view:
{code}
org.apache.phoenix.schema.ReadOnlyTableException: ERROR 505 (42000): Table is 
read only.
at 
org.apache.phoenix.query.ConnectionQueryServicesImpl.ensureTableCreated(ConnectionQueryServicesImpl.java:1072)
at 
org.apache.phoenix.query.ConnectionQueryServicesImpl.createTable(ConnectionQueryServicesImpl.java:1434)
at 
org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:2624)
at 
org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1040)
at 
org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:212)
at 
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:393)
at 
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:375)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:363)
at 
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1707)
at org.apache.PhoenixTest.main(PhoenixTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)