[jira] [Created] (PHOENIX-5515) Able to write indexed value to data table without writing to index table
Vincent Poon created PHOENIX-5515: - Summary: Able to write indexed value to data table without writing to index table Key: PHOENIX-5515 URL: https://issues.apache.org/jira/browse/PHOENIX-5515 Project: Phoenix Issue Type: Bug Affects Versions: 4.14.3 Reporter: Vincent Poon Using the 4.14.3 client, it still seems the IndexFailurePolicy is still kicking in, which disables the index on write failure. This means that while the index is in 'disabled' state, writes to the data table can happen without any writes to the index table. While in theory this might be ok since the rebuilder should eventually kick in and rebuild from the disable_timestamp, this breaks the new indexing design invariant that there should be no data table rows without a corresponding index row (potentially unverified), so this could potentially cause some unexpected behavior. Steps to repro: 1) Create data table 2) Create index table 3) "close_region" on index region from hbase shell 4) Upsert to data table Eventually after some number of retries, the index will get disabled, which means any other client can write to the data table without writing to the index table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5514) Index read repair should use index rpc handlers
[ https://issues.apache.org/jira/browse/PHOENIX-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5514: - Attachment: PHOENIX-5514.master.001.patch > Index read repair should use index rpc handlers > --- > > Key: PHOENIX-5514 > URL: https://issues.apache.org/jira/browse/PHOENIX-5514 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.3 >Reporter: Geoffrey Jacoby >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5514.master.001.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Consider base tables T1 and T2, each of which has a global mutable index, > call them IDX1 and IDX2. > RegionServer A hosts a T1 region and an IDX2 region. > RegionServer B hosts a T2 region and an IDX1 region. > > Because of prior problems, both IDX1 and IDX2 have lots of unverified rows. > Both are under heavy read-load from clients. > > IDX1 coprocs try to scan the T1 region on RS A, but can't because the > standard RPC queue is full on RS A because of all the IDX2 clients waiting on > cross-server read repairs. > IDX2 coprocs try to scan the T2 region on RS B, but can't because the > standard RPC queue is full on RS B because of the IDX1 clients waiting on > cross-server read repairs . > > It's not a permanent deadlock (eventually we'll start throwing > RegionTooBusyExceptions), but it would be unpleasant for clients. > > If read-repair used the index RPC pool instead of the standard one, this > scenario couldn't happen (unless there were _also_ too many mutable index > writes, in which case we're just saturated and back to lots of exceptions.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5514) Index read repair should use index rpc handlers
[ https://issues.apache.org/jira/browse/PHOENIX-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR reassigned PHOENIX-5514: -- Assignee: Gokcen Iskender (was: Kadir OZDEMIR) > Index read repair should use index rpc handlers > --- > > Key: PHOENIX-5514 > URL: https://issues.apache.org/jira/browse/PHOENIX-5514 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.14.3 >Reporter: Geoffrey Jacoby >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > > Consider base tables T1 and T2, each of which has a global mutable index, > call them IDX1 and IDX2. > RegionServer A hosts a T1 region and an IDX2 region. > RegionServer B hosts a T2 region and an IDX1 region. > > Because of prior problems, both IDX1 and IDX2 have lots of unverified rows. > Both are under heavy read-load from clients. > > IDX1 coprocs try to scan the T1 region on RS A, but can't because the > standard RPC queue is full on RS A because of all the IDX2 clients waiting on > cross-server read repairs. > IDX2 coprocs try to scan the T2 region on RS B, but can't because the > standard RPC queue is full on RS B because of the IDX1 clients waiting on > cross-server read repairs . > > It's not a permanent deadlock (eventually we'll start throwing > RegionTooBusyExceptions), but it would be unpleasant for clients. > > If read-repair used the index RPC pool instead of the standard one, this > scenario couldn't happen (unless there were _also_ too many mutable index > writes, in which case we're just saturated and back to lots of exceptions.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5514) Index read repair should use index rpc handlers
Geoffrey Jacoby created PHOENIX-5514: Summary: Index read repair should use index rpc handlers Key: PHOENIX-5514 URL: https://issues.apache.org/jira/browse/PHOENIX-5514 Project: Phoenix Issue Type: Improvement Affects Versions: 4.14.3 Reporter: Geoffrey Jacoby Assignee: Kadir OZDEMIR Fix For: 4.15.0, 5.1.0 Consider base tables T1 and T2, each of which has a global mutable index, call them IDX1 and IDX2. RegionServer A hosts a T1 region and an IDX2 region. RegionServer B hosts a T2 region and an IDX1 region. Because of prior problems, both IDX1 and IDX2 have lots of unverified rows. Both are under heavy read-load from clients. IDX1 coprocs try to scan the T1 region on RS A, but can't because the standard RPC queue is full on RS A because of all the IDX2 clients waiting on cross-server read repairs. IDX2 coprocs try to scan the T2 region on RS B, but can't because the standard RPC queue is full on RS B because of the IDX1 clients waiting on cross-server read repairs . It's not a permanent deadlock (eventually we'll start throwing RegionTooBusyExceptions), but it would be unpleasant for clients. If read-repair used the index RPC pool instead of the standard one, this scenario couldn't happen (unless there were _also_ too many mutable index writes, in which case we're just saturated and back to lots of exceptions.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5513) Select column label from subselect returns original column name in result
Jesse Shaffer created PHOENIX-5513:
--
Summary: Select column label from subselect returns original
column name in result
Key: PHOENIX-5513
URL: https://issues.apache.org/jira/browse/PHOENIX-5513
Project: Phoenix
Issue Type: Bug
Affects Versions: 5.0.0
Environment: OS: Windows 10
JDBC Driver: Phoenix Query Server Client 5.0.0
HBase on HDP 3.0.0
Reporter: Jesse Shaffer
When executing:
{code:java}
select col_1, col_2 from (select firstName as col_1, lastName as col_2 from
someTable)
{code}
I would expect:
||col_1||col_2||
|John|Doe|
Instead I get:
||firstName||lastName||
|John|Doe|
Workaround:
{code:java}
select col_1 as col_1, col_2 as col_2 from (select firstName as col_1, lastName
as col_2 from someTable){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4306) Add more tests for DESC sort order
[ https://issues.apache.org/jira/browse/PHOENIX-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihir Monani updated PHOENIX-4306: -- Fix Version/s: (was: 5.0.0) 5.1.0 > Add more tests for DESC sort order > -- > > Key: PHOENIX-4306 > URL: https://issues.apache.org/jira/browse/PHOENIX-4306 > Project: Phoenix > Issue Type: Test >Affects Versions: 5.0.0 >Reporter: Thomas D'Silva >Assignee: Viraj Jasani >Priority: Major > Labels: DESC, phoenix-hardening > Fix For: 5.1.0, 4.14.3 > > Attachments: PHOENIX-4306.4.x-HBase-1.3.000.patch, > PHOENIX-4306.master.001.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5511) Update documentation on secondary indexing configuration
[ https://issues.apache.org/jira/browse/PHOENIX-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] István Tóth updated PHOENIX-5511: - Attachment: PHOENIX-5511-v2.patch > Update documentation on secondary indexing configuration > > > Key: PHOENIX-5511 > URL: https://issues.apache.org/jira/browse/PHOENIX-5511 > Project: Phoenix > Issue Type: Task >Reporter: István Tóth >Assignee: István Tóth >Priority: Major > Labels: documentation > Attachments: PHOENIX-5511-v2.patch, PHOENIX-5511.patch > > > Since PHOENIX-3994 there is no need to set the > hbase.region.server.rpc.scheduler.factory.class and > hbase.rpc.controllerfactory.class properties in hbase-site.xml anymore. > However, the documentation has not been updated to reflect this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
