[jira] [Updated] (PHOENIX-6461) sqlline-thin does not include slf4j logging backend
[ https://issues.apache.org/jira/browse/PHOENIX-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6461: - Description: The Avatica client JAR that we use in the phoenix thin client JAR does not include and sfl4j backend. This in itself is not a problem, as it allows dependent project to use their preferred backend. However, we are not adding a backend in the sqlline-thin script either, which results in any log messages being dropped. We should add a log implementation in the sqlline-thin script to the classpath. Probably slf4j-simple would be the best choice. was: The Avatica client JAR that we use in the phoenix thin client JAR does not include and sfl4j backend. This in itself is not a problem, as it allows dependent project to use their preferred backend. However, we are not a backend in the sqlline-thin backend either, which results in any log messages being dropped. We should add a log implementation in the sqlline-thin script to the classpath. Probably slf4j-simple would be the best choice. > sqlline-thin does not include slf4j logging backend > --- > > Key: PHOENIX-6461 > URL: https://issues.apache.org/jira/browse/PHOENIX-6461 > Project: Phoenix > Issue Type: Bug > Components: queryserver >Reporter: Istvan Toth >Priority: Major > > The Avatica client JAR that we use in the phoenix thin client JAR does not > include and sfl4j backend. > This in itself is not a problem, as it allows dependent project to use their > preferred backend. > However, we are not adding a backend in the sqlline-thin script either, which > results in any log messages being dropped. > We should add a log implementation in the sqlline-thin script to the > classpath. > Probably slf4j-simple would be the best choice. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6461) sqlline-thin does not include slf4j logging backend
Istvan Toth created PHOENIX-6461: Summary: sqlline-thin does not include slf4j logging backend Key: PHOENIX-6461 URL: https://issues.apache.org/jira/browse/PHOENIX-6461 Project: Phoenix Issue Type: Bug Components: queryserver Reporter: Istvan Toth The Avatica client JAR that we use in the phoenix thin client JAR does not include and sfl4j backend. This in itself is not a problem, as it allows dependent project to use their preferred backend. However, we are not a backend in the sqlline-thin backend either, which results in any log messages being dropped. We should add a log implementation in the sqlline-thin script to the classpath. Probably slf4j-simple would be the best choice. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TEPHRA-318) Remove support for pre 1.3 HBase
Istvan Toth created TEPHRA-318: -- Summary: Remove support for pre 1.3 HBase Key: TEPHRA-318 URL: https://issues.apache.org/jira/browse/TEPHRA-318 Project: Phoenix Tephra Issue Type: Task Affects Versions: 0.16.1 Reporter: Istvan Toth Assignee: Poorna Chandra Fix For: 0.17.0 As discussed in TEPHRA-313, we can drop support for anything older than HBase 1.3 Apparently, we also need to re-unify some code which is identical in in all 1.3+ compatibility modules back to core. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6460) Improve the optimizer to consider all plans and prefer regular over reverse scans
[
https://issues.apache.org/jira/browse/PHOENIX-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swaroopa Kadam updated PHOENIX-6460:
Description:
In QueryOptimizerTest, following test fails, as it uses IDX over view
{code:java}
@Test
public void testChooseIndexOverTable_diffOrder() throws Exception
{
Connection conn = DriverManager.getConnection(getUrl());
conn.createStatement().execute("CREATE TABLE t (k INTEGER NOT NULL, v1 VARCHAR
NOT NULL, v2 VARCHAR CONSTRAINT" + " PK PRIMARY KEY (k, v1))
IMMUTABLE_ROWS=true"); conn.createStatement().execute("CREATE VIEW v(v4
VARCHAR) AS SELECT * FROM t"); conn.createStatement().execute("CREATE INDEX idx
ON v(v1 DESC) INCLUDE (v4)");
PhoenixStatement stmt = conn.createStatement().unwrap(PhoenixStatement.class);
QueryPlan plan = stmt.optimizeQuery("SELECT v1 FROM v ORDER BY v1");
assertEquals("V", plan.getTableRef().getTable().getTableName().getString());
}
{code}
was:
In QueryOptimizerTest, following test fails, as it uses IDX over view
@Test
public void testChooseIndexOverTable_diffOrder() throws Exception {
Connection conn = DriverManager.getConnection(getUrl());
conn.createStatement().execute("CREATE TABLE t (k INTEGER NOT NULL, v1 VARCHAR
NOT NULL, v2 VARCHAR CONSTRAINT"
+ " PK PRIMARY KEY (k, v1)) IMMUTABLE_ROWS=true");
conn.createStatement().execute("CREATE VIEW v(v4 VARCHAR) AS SELECT * FROM t");
conn.createStatement().execute("CREATE INDEX idx ON v(v1 DESC) INCLUDE (v4)");
PhoenixStatement stmt = conn.createStatement().unwrap(PhoenixStatement.class);
QueryPlan plan = stmt.optimizeQuery("SELECT v1 FROM v ORDER BY v1");
assertEquals("V", plan.getTableRef().getTable().getTableName().getString());
}
> Improve the optimizer to consider all plans and prefer regular over reverse
> scans
> -
>
> Key: PHOENIX-6460
> URL: https://issues.apache.org/jira/browse/PHOENIX-6460
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Swaroopa Kadam
>Priority: Major
> Fix For: 5.1.1, 4.17.0
>
>
> In QueryOptimizerTest, following test fails, as it uses IDX over view
>
> {code:java}
> @Test
> public void testChooseIndexOverTable_diffOrder() throws Exception
> {
> Connection conn = DriverManager.getConnection(getUrl());
> conn.createStatement().execute("CREATE TABLE t (k INTEGER NOT NULL, v1
> VARCHAR NOT NULL, v2 VARCHAR CONSTRAINT" + " PK PRIMARY KEY (k, v1))
> IMMUTABLE_ROWS=true"); conn.createStatement().execute("CREATE VIEW v(v4
> VARCHAR) AS SELECT * FROM t"); conn.createStatement().execute("CREATE INDEX
> idx ON v(v1 DESC) INCLUDE (v4)");
> PhoenixStatement stmt =
> conn.createStatement().unwrap(PhoenixStatement.class);
> QueryPlan plan = stmt.optimizeQuery("SELECT v1 FROM v ORDER BY v1");
> assertEquals("V", plan.getTableRef().getTable().getTableName().getString());
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6460) Improve the optimizer to consider all plans and prefer regular over reverse scans
Swaroopa Kadam created PHOENIX-6460:
---
Summary: Improve the optimizer to consider all plans and prefer
regular over reverse scans
Key: PHOENIX-6460
URL: https://issues.apache.org/jira/browse/PHOENIX-6460
Project: Phoenix
Issue Type: Improvement
Reporter: Swaroopa Kadam
Fix For: 5.1.1, 4.17.0
In QueryOptimizerTest, following test fails, as it uses IDX over view
@Test
public void testChooseIndexOverTable_diffOrder() throws Exception {
Connection conn = DriverManager.getConnection(getUrl());
conn.createStatement().execute("CREATE TABLE t (k INTEGER NOT NULL, v1 VARCHAR
NOT NULL, v2 VARCHAR CONSTRAINT"
+ " PK PRIMARY KEY (k, v1)) IMMUTABLE_ROWS=true");
conn.createStatement().execute("CREATE VIEW v(v4 VARCHAR) AS SELECT * FROM t");
conn.createStatement().execute("CREATE INDEX idx ON v(v1 DESC) INCLUDE (v4)");
PhoenixStatement stmt = conn.createStatement().unwrap(PhoenixStatement.class);
QueryPlan plan = stmt.optimizeQuery("SELECT v1 FROM v ORDER BY v1");
assertEquals("V", plan.getTableRef().getTable().getTableName().getString());
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6351) PhoenixMRJobUtil getActiveResourceManagerAddress logic fails on pseudodistributed cluster
[ https://issues.apache.org/jira/browse/PHOENIX-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richárd Antal resolved PHOENIX-6351. Fix Version/s: 5.1.2 5.2.0 4.17.0 Resolution: Fixed > PhoenixMRJobUtil getActiveResourceManagerAddress logic fails on > pseudodistributed cluster > - > > Key: PHOENIX-6351 > URL: https://issues.apache.org/jira/browse/PHOENIX-6351 > Project: Phoenix > Issue Type: Bug > Components: core >Reporter: Istvan Toth >Assignee: Richárd Antal >Priority: Minor > Fix For: 4.17.0, 5.2.0, 5.1.2 > > > In > org.apache.phoenix.util.PhoenixMRJobUtil.getActiveResourceManagerAddress(Configuration, > String) > We first check if YarnConfiguration.DEFAULT_RM_WEBAPP_ADDRESS is changed from > the default, and if it isn't, we try to get the HA RM from ZK. > This fails with the default config on a pseudo-distributed cluster. > We should probably try to get the HA RM first, and fall back to > YarnConfiguration.RM_WEBAPP_ADDRESS if that one is not available. -- This message was sent by Atlassian Jira (v8.3.4#803005)
