[jira] [Updated] (PHOENIX-6434) Secondary Indexes on PHOENIX_ROW_TIMESTAMP()
[ https://issues.apache.org/jira/browse/PHOENIX-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir Ozdemir updated PHOENIX-6434: --- Attachment: PHOENIX-6434.master.002.patch > Secondary Indexes on PHOENIX_ROW_TIMESTAMP() > > > Key: PHOENIX-6434 > URL: https://issues.apache.org/jira/browse/PHOENIX-6434 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.1.0, 4.16.0 >Reporter: Kadir Ozdemir >Priority: Major > Attachments: PHOENIX-6434.4.x.001.patch, PHOENIX-6434.4.x.002.patch, > PHOENIX-6434.4.x.003.patch, PHOENIX-6434.4.x.004.patch, > PHOENIX-6434.master.001.patch, PHOENIX-6434.master.002.patch > > > PHOENIX-5629 introduced the function PHOENIX_ROW_TIMESTAMP() that returns the > last modified time of a row. PHOENIX_ROW_TIMESTAMP() can be used as a > projection column and referred in a WHERE clause. It is desirable to have > indexes on row timestamps. This will result in fast time range queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6444) Extend Cell Tags to Delete object for Indexer coproc
[ https://issues.apache.org/jira/browse/PHOENIX-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby resolved PHOENIX-6444. -- Fix Version/s: 5.2.0 4.17.0 Resolution: Fixed Merged to 4.x and master. Thanks for the patch, [~shahrs87]! > Extend Cell Tags to Delete object for Indexer coproc > > > Key: PHOENIX-6444 > URL: https://issues.apache.org/jira/browse/PHOENIX-6444 > Project: Phoenix > Issue Type: Improvement > Components: core >Reporter: Rushabh Shah >Assignee: Rushabh Shah >Priority: Major > Fix For: 4.17.0, 5.2.0 > > > In PHOENIX-6213 we added support for adding source of operation cell tag to > Delete Markers. But we added the logic to create TagRewriteCell and add it to > DeleteMarker only in IndexRegionObserver coproc. I missed adding the same > logic to Indexer coproc. Thank you [~tkhurana] for finding this bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6453) Possible ArrayIndexOutOfBoundsException while preparing scan start key with multiple key range queries
Rajeshbabu Chintaguntla created PHOENIX-6453:
Summary: Possible ArrayIndexOutOfBoundsException while preparing
scan start key with multiple key range queries
Key: PHOENIX-6453
URL: https://issues.apache.org/jira/browse/PHOENIX-6453
Project: Phoenix
Issue Type: Bug
Reporter: Rajeshbabu Chintaguntla
Assignee: Rajeshbabu Chintaguntla
There is possible AIOOE when there are multiple key range conditions on columns
in a query.
{noformat}
java.lang.ArrayIndexOutOfBoundsException: 25
at org.apache.phoenix.util.ScanUtil.setKey(ScanUtil.java:474)
at org.apache.phoenix.util.ScanUtil.setKey(ScanUtil.java:408)
at org.apache.phoenix.util.ScanUtil.getKey(ScanUtil.java:380)
at org.apache.phoenix.util.ScanUtil.getMinKey(ScanUtil.java:353)
at org.apache.phoenix.compile.ScanRanges.create(ScanRanges.java:134)
at
org.apache.phoenix.compile.WhereOptimizer.pushKeyExpressionsToScan(WhereOptimizer.java:355)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:171)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:118)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:747)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:674)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:251)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:501)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:464)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:306)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:295)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:287)
at
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1930)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6452) cache-apache-client-artifact.sh stopped working
[ https://issues.apache.org/jira/browse/PHOENIX-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved PHOENIX-6452. -- Resolution: Fixed Committed to master and 5.1. Not relevant for 4.x Thanks for the extra-quick review [~vjasani] > cache-apache-client-artifact.sh stopped working > --- > > Key: PHOENIX-6452 > URL: https://issues.apache.org/jira/browse/PHOENIX-6452 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.2 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Critical > Fix For: 5.2.0, 5.1.2 > > > URL generated by the script no longer downloads the artifact. > The following URL format works: > https://www.apache.org/dyn/closer.lua/hbase/2.4.2/hbase-2.4.2-src.tar.gz?action=download -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6452) cache-apache-client-artifact.sh stopped working
[ https://issues.apache.org/jira/browse/PHOENIX-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6452: - Fix Version/s: 5.1.2 5.2.0 > cache-apache-client-artifact.sh stopped working > --- > > Key: PHOENIX-6452 > URL: https://issues.apache.org/jira/browse/PHOENIX-6452 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.2 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Critical > Fix For: 5.2.0, 5.1.2 > > > URL generated by the script no longer downloads the artifact. > The following URL format works: > https://www.apache.org/dyn/closer.lua/hbase/2.4.2/hbase-2.4.2-src.tar.gz?action=download -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6452) cache-apache-client-artifact.sh stopped working
Istvan Toth created PHOENIX-6452: Summary: cache-apache-client-artifact.sh stopped working Key: PHOENIX-6452 URL: https://issues.apache.org/jira/browse/PHOENIX-6452 Project: Phoenix Issue Type: Bug Components: core Affects Versions: 5.2.0, 5.1.2 Reporter: Istvan Toth Assignee: Istvan Toth URL generated by the script no longer downloads the artifact. The following URL format works: https://www.apache.org/dyn/closer.lua/hbase/2.4.2/hbase-2.4.2-src.tar.gz?action=download -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6451) Update joni and jcodings versions
Richárd Antal created PHOENIX-6451: -- Summary: Update joni and jcodings versions Key: PHOENIX-6451 URL: https://issues.apache.org/jira/browse/PHOENIX-6451 Project: Phoenix Issue Type: Task Reporter: Richárd Antal Assignee: Richárd Antal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6449) Cannot start minicluster in github CI check for connectors
[ https://issues.apache.org/jira/browse/PHOENIX-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6449: - Fix Version/s: (was: queryserver-6.0.0) connectors-6.0.0 > Cannot start minicluster in github CI check for connectors > -- > > Key: PHOENIX-6449 > URL: https://issues.apache.org/jira/browse/PHOENIX-6449 > Project: Phoenix > Issue Type: Bug > Components: connectors >Affects Versions: connectors-6.0.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: connectors-6.0.0 > > > mvn verify cannot start minicluster when run by github actions. > It works locally. > Most likely a problem with name resolution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Separating client and server side code
(The dependency PDF is attached to the ticket, please see it there.) The separation is coming along nicely, I was able to run a successful e2e test with the separated branch and the spark connector. This got me thinking about how we handle the dependent projects (connectors and queryserver), and what would be the best way to go forward. The use cases I think we need to cover: - HBase server components for HBase classpath (no change) - Standalone JDBC driver (for sqlline, gui clients, and apps that do not include other components of the Hadoop stack) - JDBC driver that works with existing HBase client on classpath - JDBC driver that works with existing shaded HBase client on classpath - mapreduce functionality for connectors that works with unshaded HBase - mapreduce functionality for connectors that works with shaded HBase - running the Phoenix mapreduce tools Updated proposal for shaded phoenix artifacts to generate: *phoenix-server*: (no change) phoenix-client, phoenix-mapreduce, and phoenix-connectors, with their own dependencies, but without the hadoop and hbase dependencies and phoenix-hbase-compat. *phoenix-client*: (no change) phoenix-client, phoenix-mapreduce, and phoenix-connectors, with all dependencies, including logging and phoenix-hbase-compat. I don't see the use case for it, but we may need to keep it for backwards compatibility, or use this name for phoenix-client-lite. *phoenix-client-embedded*: (no change) phoenix-client, phoenix-mapreduce, and phoenix-connectors, with all dependencies, except logging and phoenix-hbase-compat. I don't see the use case for it, but we may need to keep it for backwards compatibility, or use this name for phoenix-client-lite-embedded. *phoenix-client-lite-embedded* : phoenix-core, and all of its dependencies, without the slf4j-logj4 backend and log4j libraries, and without phoenix-hbase-compat. For connectors, and applications where slf4j is already used and set up. The benefit of the artifact is also somewhat dubious. In most cases it can be replaced with phoenix-client-byo-hbase + hbase-shaded-client + phoenix-hbase-compat-X *phoenix-client-lite* : phoenix-core, and all of its dependencies including hbase and hadoop clients jars, with the slf4j-logj4 backend and log4j libraries, and phoenix-hbase-compat. For gui clients, and applications that do not have their own logging setup, or do not use slf4j. *phoenix-client-byo-hbase*: phoenix-client-lite-embedded, without the hbase and hadoop dependencies, For connectors where Hadoop and HBase is already on the classpath, or apps that also use HBase/Hadoop directly. *phoenix-client-byo-shaded-hbase*: phoenix-client-byo-hbase, with the necessary relocations to work with hbase-shade-client.jar For connectors where Hadoop and shaded HBase is already on the classpath, or apps that also use (shaded) HBase directly. *phoenix-mapreduce-for-shaded-hbase*: phoenix-mapreduce, with some relocations to work with hbase-shaded-mapreduce.jar. Does not include any dependencies. Standard phoenix-mapreduce depends on hbase-mapreduce (plus dependencies), and phoenix-client-byo-hbase. If you use phoenix-client-byo-shaded-hbase, then you need the same relocations in phoenix-mapreduce as you do in phoenix-client-byo-shaded-hbase to handle the API differences. Note that in this proposal only *phoenix-client-lite, phoenix-client-lite-embedded* and the legacy* phoenix-client *and *phoenix-client-embedded* (the artifacts that include Hadoop+Hbase) would include phoenix-hbase-compat, and would have binaries pre-built for all hbase profiles. For all other use cases, including phoenix-server, the necessary phoenix-hbase-compat-X jar would need to be explicitly added. It is also possible to leave every existing shaded artifact as is, and simply add the new ones, which would minimize the disruption to existing workflows/scripts, but would further inflate the assembly size and maven artifacts. I also think that we should stop building shaded connector artifacts, and instead document which phoenix client variant, and what additional dependencies are needed to get each connector working (See below) *QueryServer:* As a standalone process, without the requirement to work with other components, it can run with almost anything. The legacy phoenix-client, phoenix-client-lite, or even phoenix-core is fine, as long as we add the necessary dependencies to its classpath. *Spark:* Spark already has Hadoop on the classpath, but it doesn't include HBase. The official HBase connector depends on hbase-shaded mapreduce. To interoperate with this, we need something that can work on top of the HBase connector and its dependencies: *phoenix-client-byo-shaded-hbase *+ phoenix-hbase-compat *+ phoenix-mapreduce-for-shaded-hbase + phoenix5-spark* *Hive:* Hive is a big headache, because as of 3.x it includes an ancient HBase version by default, which conflicts with everything. The issue (and a partial fix for Hive 4.0) is detailed in HIVE-24473.
