[jira] [Updated] (PHOENIX-5766) PhoenixMetricsIT failure in 4.x for HBase 1.3
[ https://issues.apache.org/jira/browse/PHOENIX-5766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-5766: - Affects Version/s: 4.16.0 > PhoenixMetricsIT failure in 4.x for HBase 1.3 > - > > Key: PHOENIX-5766 > URL: https://issues.apache.org/jira/browse/PHOENIX-5766 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > org.apache.phoenix.monitoring.PhoenixMetricsIT fails when run with > -Dhbase.profile=1.3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5766) PhoenixMetricsIT failure in 4.x for HBase 1.3
Istvan Toth created PHOENIX-5766: Summary: PhoenixMetricsIT failure in 4.x for HBase 1.3 Key: PHOENIX-5766 URL: https://issues.apache.org/jira/browse/PHOENIX-5766 Project: Phoenix Issue Type: Bug Reporter: Istvan Toth Assignee: Istvan Toth org.apache.phoenix.monitoring.PhoenixMetricsIT fails when run with -Dhbase.profile=1.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5762) Update jackson
[ https://issues.apache.org/jira/browse/PHOENIX-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-5762: - Fix Version/s: 5.1.0 > Update jackson > -- > > Key: PHOENIX-5762 > URL: https://issues.apache.org/jira/browse/PHOENIX-5762 > Project: Phoenix > Issue Type: Task >Affects Versions: 5.1.0, 4.16.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: 5.1.0 > > Attachments: PHOENIX-5762.master.v1.patch > > Time Spent: 40m > Remaining Estimate: 0h > > The jackson library that Phoenix depends on is positively ancient, with all > of its implications. > Update to the latest com.fasterxml release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests
[ https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5607: -- Fix Version/s: 5.1.0 > Client-server backward compatibility tests > --- > > Key: PHOENIX-5607 > URL: https://issues.apache.org/jira/browse/PHOENIX-5607 > Project: Phoenix > Issue Type: Test >Affects Versions: 4.15.0 >Reporter: Lars Hofhansl >Assignee: Sandeep Guggilam >Priority: Blocker > Labels: phoenix-hardening > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, > PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, > PHOENIX-5607.4.x-HBase-1.3.v4.patch, PHOENIX-5607.4.x-HBase-1.3.v5.patch, > PHOENIX-5607.master.v1.patch > > Time Spent: 2h > Remaining Estimate: 0h > > Filing this as a blocker for 4.16.0. > As we've seen with the various failed attempts to release 4.15.0 Phoenix' > backwards compatibility story is weak, and lacks tests - in fact there're no > tests. > We should not allow to ship 4.16.0 without improving that and without tests. > [~ckulkarni], [~gjacoby] , FYI, what we discussed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5718) GetTable builds a table excluding the given clientTimeStamp
[ https://issues.apache.org/jira/browse/PHOENIX-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5718: -- Attachment: PHOENIX-5718.master.v2.patch > GetTable builds a table excluding the given clientTimeStamp > --- > > Key: PHOENIX-5718 > URL: https://issues.apache.org/jira/browse/PHOENIX-5718 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5718.4.x-HBase-1.3.v1.patch, > PHOENIX-5718.4.x-HBase-1.3.v2.patch, PHOENIX-5718.master.v1.patch, > PHOENIX-5718.master.v2.patch, PHOENIX-5718.master.v2.patch > > > Here is the scenario tested: > # Brought up a server with 4.16 where new columns are added but not added as > part of upgrade path > # Connect with 4.14 client > # Connect with a 4.16 client - this will throw an exception as the new > columns added as part of 4.16 were not added as part of upgrade path > # Now the code will force update the cache in > PhoenixStatement#executeQuery() method > # Now the buildTable is removing even the columns added as part of 4.15 , > the reason being we are passing the clientTimeStamp to build table ( say 29 > is the timestamp for column added for 4.15) but the table is scanning rows > EXCLUDING the passed clientTimeSTamp as the Scan#setTimeRange method excludes > the end time stamp > The passing of clientTimeStamp to build table is in > MetaDataEndPointImpl#doGetTable method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5632) Add more information to SYSTEM.TASK TASK_DATA field apart from the task status
[ https://issues.apache.org/jira/browse/PHOENIX-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Feng updated PHOENIX-5632: Description: It would be helpful for debugging if we could add more information to the TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task status. For example, in failures cases, perhaps we can add the stack trace for the failing task. Ideas: * Time taken for task to complete * Name(s) of deleted child view(s)/table(s) per task * Task_type column is represented by int; may be useful to include task type in task_data column was: It would be helpful for debugging if we could add more information to the TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task status. For example, in failures cases, perhaps we can add the stack trace for the failing task. Ideas: * Time taken for task to complete > Add more information to SYSTEM.TASK TASK_DATA field apart from the task status > -- > > Key: PHOENIX-5632 > URL: https://issues.apache.org/jira/browse/PHOENIX-5632 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Chinmay Kulkarni >Assignee: Christine Feng >Priority: Minor > Labels: beginner, newbie > Fix For: 4.15.1 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be helpful for debugging if we could add more information to the > TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task > status. For example, in failures cases, perhaps we can add the stack trace > for the failing task. > > Ideas: > * Time taken for task to complete > * Name(s) of deleted child view(s)/table(s) per task > * Task_type column is represented by int; may be useful to include task type > in task_data column -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5632) Add more information to SYSTEM.TASK TASK_DATA field apart from the task status
[ https://issues.apache.org/jira/browse/PHOENIX-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Feng updated PHOENIX-5632: Description: It would be helpful for debugging if we could add more information to the TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task status. For example, in failures cases, perhaps we can add the stack trace for the failing task. Ideas: * Time taken for task to complete was:It would be helpful for debugging if we could add more information to the TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task status. For example, in failures cases, perhaps we can add the stack trace for the failing task. > Add more information to SYSTEM.TASK TASK_DATA field apart from the task status > -- > > Key: PHOENIX-5632 > URL: https://issues.apache.org/jira/browse/PHOENIX-5632 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.15.0 >Reporter: Chinmay Kulkarni >Assignee: Christine Feng >Priority: Minor > Labels: beginner, newbie > Fix For: 4.15.1 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be helpful for debugging if we could add more information to the > TASK_DATA json that is upserted into SYSTEM.TASK apart from just the task > status. For example, in failures cases, perhaps we can add the stack trace > for the failing task. > > Ideas: > * Time taken for task to complete -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
[
https://issues.apache.org/jira/browse/PHOENIX-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Antal updated PHOENIX-5065:
---
Attachment: PHOENIX-5065.master.v5.patch
> Inconsistent treatment of NULL and empty string
> ---
>
> Key: PHOENIX-5065
> URL: https://issues.apache.org/jira/browse/PHOENIX-5065
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Geoffrey Jacoby
>Priority: Major
> Attachments: PHOENIX-5065.master.v1.patch,
> PHOENIX-5065.master.v2.patch, PHOENIX-5065.master.v3.patch,
> PHOENIX-5065.master.v4.patch, PHOENIX-5065.master.v5.patch
>
>
> Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
> doesn't handle them consistently internally either.
> In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
> for empty string and NULL to be equivalent. That's inconsistent with other
> SQL dialects (in which NULL is never equal to anything, including itself),
> but if that's our documented behavior, then that's fine unless PHOENIX-2422
> to change it is ever worked.
> But consider the following queries:
> {code:java}
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
> -- Returns some number of rows. Call it N
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
> -- Returns N rows. Note that FOO does not exist, and is just a nonsense string
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
> --Returns 0 rows, but slowly
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5718) GetTable builds a table excluding the given clientTimeStamp
[ https://issues.apache.org/jira/browse/PHOENIX-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5718: -- Attachment: PHOENIX-5718.master.v2.patch > GetTable builds a table excluding the given clientTimeStamp > --- > > Key: PHOENIX-5718 > URL: https://issues.apache.org/jira/browse/PHOENIX-5718 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5718.4.x-HBase-1.3.v1.patch, > PHOENIX-5718.4.x-HBase-1.3.v2.patch, PHOENIX-5718.master.v1.patch, > PHOENIX-5718.master.v2.patch > > > Here is the scenario tested: > # Brought up a server with 4.16 where new columns are added but not added as > part of upgrade path > # Connect with 4.14 client > # Connect with a 4.16 client - this will throw an exception as the new > columns added as part of 4.16 were not added as part of upgrade path > # Now the code will force update the cache in > PhoenixStatement#executeQuery() method > # Now the buildTable is removing even the columns added as part of 4.15 , > the reason being we are passing the clientTimeStamp to build table ( say 29 > is the timestamp for column added for 4.15) but the table is scanning rows > EXCLUDING the passed clientTimeSTamp as the Scan#setTimeRange method excludes > the end time stamp > The passing of clientTimeStamp to build table is in > MetaDataEndPointImpl#doGetTable method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5718) GetTable builds a table excluding the given clientTimeStamp
[ https://issues.apache.org/jira/browse/PHOENIX-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5718: -- Attachment: (was: PHOENIX-5718.master.v2.patch) > GetTable builds a table excluding the given clientTimeStamp > --- > > Key: PHOENIX-5718 > URL: https://issues.apache.org/jira/browse/PHOENIX-5718 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5718.4.x-HBase-1.3.v1.patch, > PHOENIX-5718.4.x-HBase-1.3.v2.patch, PHOENIX-5718.master.v1.patch > > > Here is the scenario tested: > # Brought up a server with 4.16 where new columns are added but not added as > part of upgrade path > # Connect with 4.14 client > # Connect with a 4.16 client - this will throw an exception as the new > columns added as part of 4.16 were not added as part of upgrade path > # Now the code will force update the cache in > PhoenixStatement#executeQuery() method > # Now the buildTable is removing even the columns added as part of 4.15 , > the reason being we are passing the clientTimeStamp to build table ( say 29 > is the timestamp for column added for 4.15) but the table is scanning rows > EXCLUDING the passed clientTimeSTamp as the Scan#setTimeRange method excludes > the end time stamp > The passing of clientTimeStamp to build table is in > MetaDataEndPointImpl#doGetTable method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5765) Add unit tests for prepareIndexMutationsForRebuild() of IndexRebuildRegionScanner
[ https://issues.apache.org/jira/browse/PHOENIX-5765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swaroopa Kadam updated PHOENIX-5765: Summary: Add unit tests for prepareIndexMutationsForRebuild() of IndexRebuildRegionScanner (was: Unit-tests for prepareIndexMutationsForRebuild) > Add unit tests for prepareIndexMutationsForRebuild() of > IndexRebuildRegionScanner > - > > Key: PHOENIX-5765 > URL: https://issues.apache.org/jira/browse/PHOENIX-5765 > Project: Phoenix > Issue Type: Sub-task >Reporter: Swaroopa Kadam >Assignee: Weiming Wang >Priority: Major > > Unit-tests for prepareIndexMutationsForRebuild -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5765) Unit-tests for prepareIndexMutationsForRebuild
Swaroopa Kadam created PHOENIX-5765: --- Summary: Unit-tests for prepareIndexMutationsForRebuild Key: PHOENIX-5765 URL: https://issues.apache.org/jira/browse/PHOENIX-5765 Project: Phoenix Issue Type: Sub-task Reporter: Swaroopa Kadam Assignee: Weiming Wang Unit-tests for prepareIndexMutationsForRebuild -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5760) Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row distribution
[ https://issues.apache.org/jira/browse/PHOENIX-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wong updated PHOENIX-5760: - Attachment: PHOENIX-5760.patch > Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row > distribution > -- > > Key: PHOENIX-5760 > URL: https://issues.apache.org/jira/browse/PHOENIX-5760 > Project: Phoenix > Issue Type: Improvement >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Minor > Attachments: PHOENIX-5760.patch > > > In order to run pherf test closer to how users do QueryMore we want to extend > the Sequential datatype to integer fields with guaranteed values. > In general we want to be able to generate data for a column from 1..N in > pherf contiguously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5760) Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row distribution
[ https://issues.apache.org/jira/browse/PHOENIX-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wong updated PHOENIX-5760: - Attachment: (was: PHOENIX-5760.patch) > Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row > distribution > -- > > Key: PHOENIX-5760 > URL: https://issues.apache.org/jira/browse/PHOENIX-5760 > Project: Phoenix > Issue Type: Improvement >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Minor > Attachments: PHOENIX-5760.patch > > > In order to run pherf test closer to how users do QueryMore we want to extend > the Sequential datatype to integer fields with guaranteed values. > In general we want to be able to generate data for a column from 1..N in > pherf contiguously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5760) Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row distribution
[ https://issues.apache.org/jira/browse/PHOENIX-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wong updated PHOENIX-5760: - Attachment: PHOENIX-5760.patch > Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row > distribution > -- > > Key: PHOENIX-5760 > URL: https://issues.apache.org/jira/browse/PHOENIX-5760 > Project: Phoenix > Issue Type: Improvement >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Minor > Attachments: PHOENIX-5760.patch > > > In order to run pherf test closer to how users do QueryMore we want to extend > the Sequential datatype to integer fields with guaranteed values. > In general we want to be able to generate data for a column from 1..N in > pherf contiguously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5760) Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row distribution
[ https://issues.apache.org/jira/browse/PHOENIX-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wong updated PHOENIX-5760: - Attachment: (was: PHOENIX-5760.patch) > Pherf Support Sequential Datatypes for INTEGER type fields and have fixed row > distribution > -- > > Key: PHOENIX-5760 > URL: https://issues.apache.org/jira/browse/PHOENIX-5760 > Project: Phoenix > Issue Type: Improvement >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Minor > > In order to run pherf test closer to how users do QueryMore we want to extend > the Sequential datatype to integer fields with guaranteed values. > In general we want to be able to generate data for a column from 1..N in > pherf contiguously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5764) Update website to reflect the new 4.x branch
Istvan Toth created PHOENIX-5764: Summary: Update website to reflect the new 4.x branch Key: PHOENIX-5764 URL: https://issues.apache.org/jira/browse/PHOENIX-5764 Project: Phoenix Issue Type: Task Reporter: Istvan Toth Assignee: Istvan Toth -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5763) Add Jenkins job for the unified 4.x branch
Istvan Toth created PHOENIX-5763: Summary: Add Jenkins job for the unified 4.x branch Key: PHOENIX-5763 URL: https://issues.apache.org/jira/browse/PHOENIX-5763 Project: Phoenix Issue Type: Task Affects Versions: 4.16.0 Reporter: Istvan Toth Assignee: Istvan Toth This should be almost identical to the master matrix job. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Unified 4.x branch now live
Hi! I've just pushed the unified 4.x branch discussed in https://issues.apache.org/jira/browse/PHOENIX-5721, and on the mailing list. >From now on, 4.x-HBase-1.3, 4.x-HBase-1.4 and 4.x-HBase 1.5 should be considered obsolete, all new 4.x development should occur on the 4.x branch. https://github.com/apache/phoenix/tree/4.x The build options are detailed in the new README.md file, but a short recap: You can specify the HBase version to build, test, and shade against through the hbase.profile system property. i.e: mvn install -Dhbase.profile=1.5 mvn install -Dhbase.profile=1.4 mvn install -Dhbase.profile=1.3 will build, test, and package Phoenix with the corresponding HBase version, and the necessary compatibility classes. The default is hbase.profile=1.5. Please do not push any new work into the old branches. The 4.15 branches continue as before. I will add the new test matrix jenkins jobs soon, but it may take a few days until I shake out the problems. If there are any questions, please let me know. If there are any bugs resulting from the unification work, please also let me know, and open JIRAs. regards Istvan
[jira] [Updated] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
[
https://issues.apache.org/jira/browse/PHOENIX-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Antal updated PHOENIX-5065:
---
Attachment: PHOENIX-5065.master.v4.patch
> Inconsistent treatment of NULL and empty string
> ---
>
> Key: PHOENIX-5065
> URL: https://issues.apache.org/jira/browse/PHOENIX-5065
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Geoffrey Jacoby
>Priority: Major
> Attachments: PHOENIX-5065.master.v1.patch,
> PHOENIX-5065.master.v2.patch, PHOENIX-5065.master.v3.patch,
> PHOENIX-5065.master.v4.patch
>
>
> Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
> doesn't handle them consistently internally either.
> In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
> for empty string and NULL to be equivalent. That's inconsistent with other
> SQL dialects (in which NULL is never equal to anything, including itself),
> but if that's our documented behavior, then that's fine unless PHOENIX-2422
> to change it is ever worked.
> But consider the following queries:
> {code:java}
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
> -- Returns some number of rows. Call it N
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
> -- Returns N rows. Note that FOO does not exist, and is just a nonsense string
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
> --Returns 0 rows, but slowly
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-5762) Update jackson
Istvan Toth created PHOENIX-5762: Summary: Update jackson Key: PHOENIX-5762 URL: https://issues.apache.org/jira/browse/PHOENIX-5762 Project: Phoenix Issue Type: Task Affects Versions: 5.1.0, 4.16.0 Reporter: Istvan Toth Assignee: Istvan Toth The jackson library that Phoenix depends on is positively ancient, with all of its implications. Update to the latest com.fasterxml release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5761) sqlline-thin kerberos logic too aggressive
[ https://issues.apache.org/jira/browse/PHOENIX-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-5761: Assignee: Istvan Toth > sqlline-thin kerberos logic too aggressive > -- > > Key: PHOENIX-5761 > URL: https://issues.apache.org/jira/browse/PHOENIX-5761 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.0, 4.16.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The kerberos login in logic in SqllineWrapper.java tries to read the hbase > configuration, and tries to log in into kerberos if it decides that the HBase > instance is kerberized. > While this is fine in many use cases, it causes unintended failures in at > least the following cases: > * When trying to connect via Knox, which usually does not use kerberos > * When trying to connect to a a PQS that is not using the same HBase config > as the current host. > This is true even if the user explicitly specifies BASIC authentication. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5761) sqlline-thin kerberos logic too aggressive
[ https://issues.apache.org/jira/browse/PHOENIX-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-5761: - Description: The kerberos login in logic in SqllineWrapper.java tries to read the hbase configuration, and tries to log in into kerberos if it decides that the HBase instance is kerberized. While this is fine in many use cases, it causes unintended failures in at least the following cases: * When trying to connect via Knox, which usually does not use kerberos * When trying to connect to a a PQS that is not using the same HBase config as the current host. This is true even if the user explicitly specifies BASIC authentication. > sqlline-thin kerberos logic too aggressive > -- > > Key: PHOENIX-5761 > URL: https://issues.apache.org/jira/browse/PHOENIX-5761 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.0, 4.16.0 >Reporter: Istvan Toth >Priority: Major > > The kerberos login in logic in SqllineWrapper.java tries to read the hbase > configuration, and tries to log in into kerberos if it decides that the HBase > instance is kerberized. > While this is fine in many use cases, it causes unintended failures in at > least the following cases: > * When trying to connect via Knox, which usually does not use kerberos > * When trying to connect to a a PQS that is not using the same HBase config > as the current host. > This is true even if the user explicitly specifies BASIC authentication. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5761) sqlline-thin kerberos logic too aggressive
Istvan Toth created PHOENIX-5761: Summary: sqlline-thin kerberos logic too aggressive Key: PHOENIX-5761 URL: https://issues.apache.org/jira/browse/PHOENIX-5761 Project: Phoenix Issue Type: Bug Affects Versions: 5.1.0, 4.16.0 Reporter: Istvan Toth -- This message was sent by Atlassian Jira (v8.3.4#803005)
