[jira] [Commented] (PHOENIX-3394) Handle SequenceResolving through ConnectionQueryServices interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-3394:
-

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

https://github.com/apache/phoenix/pull/220#discussion_r86287165
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/PhoenixSchema.java ---
@@ -329,24 +333,14 @@ private TableRef fixTableMultiTenancy(TableRef 
tableRef) throws SQLException {
 
 private PhoenixSequence resolveSequence(String name) {
 try {
-// FIXME: Do this the same way as resolving a table after 
PHOENIX-2489.
-String tenantId = pc.getTenantId() == null ? null : 
pc.getTenantId().getString();
-String q = "select 1 from " + 
PhoenixDatabaseMetaData.SYSTEM_SEQUENCE
-+ " where " + PhoenixDatabaseMetaData.SEQUENCE_SCHEMA
-+ (schemaName == null ? " is null" : " = '" + 
schemaName + "'")
-+ " and " + PhoenixDatabaseMetaData.SEQUENCE_NAME
-+ " = '" + name + "'"
-+ " and " + PhoenixDatabaseMetaData.TENANT_ID
-+ (tenantId == null ? " is null" : " = '" + tenantId + 
"'");
-ResultSet rs = pc.createStatement().executeQuery(q);
-if (rs.next()) {
-return new PhoenixSequence(schemaName, name, pc);
-}
-} catch (SQLException e) {
-throw new RuntimeException(e);
+SequenceManager manager = new 
SequenceManager((PhoenixStatement)pc.createStatement());
+manager.newSequenceReference(pc.getTenantId(), 
TableName.createNormalized(schemaName, name) , null, 
SequenceValueParseNode.Op.NEXT_VALUE);
--- End diff --

@JamesRTaylor Could you also take a look here to make sure that the method 
is called with right parameters? And is there a chance (and a need) we can 
avoid creating a new "Statement" each time?


> Handle SequenceResolving through ConnectionQueryServices interface
> --
>
> Key: PHOENIX-3394
> URL: https://issues.apache.org/jira/browse/PHOENIX-3394
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
>
> Tons of unit tests have this same stack trace. It appears that this call 
> shouldn't reach ConnectionlessQueryServicesImpl.getTable?
> {code}
> Caused by: java.lang.UnsupportedOperationException
>   at 
> org.apache.phoenix.query.ConnectionlessQueryServicesImpl.getTable(ConnectionlessQueryServicesImpl.java:157)
>   at 
> org.apache.phoenix.query.DelegateConnectionQueryServices.getTable(DelegateConnectionQueryServices.java:70)
>   at 
> org.apache.phoenix.execute.MutationState.getHTable(MutationState.java:360)
>   at 
> org.apache.phoenix.iterate.TableResultIterator.(TableResultIterator.java:101)
>   at 
> org.apache.phoenix.iterate.DefaultTableResultIteratorFactory.newIterator(DefaultTableResultIteratorFactory.java:33)
>   at 
> org.apache.phoenix.iterate.ParallelIterators.submitWork(ParallelIterators.java:104)
>   at 
> org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:871)
>   ... 71 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3394) Handle SequenceResolving through ConnectionQueryServices interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-3394:
-

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

https://github.com/apache/phoenix/pull/220#discussion_r86287255
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/calcite/CalciteIT.java ---
@@ -1315,6 +1315,17 @@ public void initTable() throws Exception {
 {6L, "00A323122312312"},
 {8L, "00A423122312312"}})
 .close();
+
--- End diff --

It's nice to add more test case in CalciteIT, but I'm just curious, why 
aren't existing tests in testSequence() sufficient?


> Handle SequenceResolving through ConnectionQueryServices interface
> --
>
> Key: PHOENIX-3394
> URL: https://issues.apache.org/jira/browse/PHOENIX-3394
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
>
> Tons of unit tests have this same stack trace. It appears that this call 
> shouldn't reach ConnectionlessQueryServicesImpl.getTable?
> {code}
> Caused by: java.lang.UnsupportedOperationException
>   at 
> org.apache.phoenix.query.ConnectionlessQueryServicesImpl.getTable(ConnectionlessQueryServicesImpl.java:157)
>   at 
> org.apache.phoenix.query.DelegateConnectionQueryServices.getTable(DelegateConnectionQueryServices.java:70)
>   at 
> org.apache.phoenix.execute.MutationState.getHTable(MutationState.java:360)
>   at 
> org.apache.phoenix.iterate.TableResultIterator.(TableResultIterator.java:101)
>   at 
> org.apache.phoenix.iterate.DefaultTableResultIteratorFactory.newIterator(DefaultTableResultIteratorFactory.java:33)
>   at 
> org.apache.phoenix.iterate.ParallelIterators.submitWork(ParallelIterators.java:104)
>   at 
> org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:871)
>   ... 71 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #220: PHOENIX-3394 Handle SequenceResolving through Con...

[maryannxue]

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

https://github.com/apache/phoenix/pull/220#discussion_r86287165
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/PhoenixSchema.java ---
@@ -329,24 +333,14 @@ private TableRef fixTableMultiTenancy(TableRef 
tableRef) throws SQLException {
 
 private PhoenixSequence resolveSequence(String name) {
 try {
-// FIXME: Do this the same way as resolving a table after 
PHOENIX-2489.
-String tenantId = pc.getTenantId() == null ? null : 
pc.getTenantId().getString();
-String q = "select 1 from " + 
PhoenixDatabaseMetaData.SYSTEM_SEQUENCE
-+ " where " + PhoenixDatabaseMetaData.SEQUENCE_SCHEMA
-+ (schemaName == null ? " is null" : " = '" + 
schemaName + "'")
-+ " and " + PhoenixDatabaseMetaData.SEQUENCE_NAME
-+ " = '" + name + "'"
-+ " and " + PhoenixDatabaseMetaData.TENANT_ID
-+ (tenantId == null ? " is null" : " = '" + tenantId + 
"'");
-ResultSet rs = pc.createStatement().executeQuery(q);
-if (rs.next()) {
-return new PhoenixSequence(schemaName, name, pc);
-}
-} catch (SQLException e) {
-throw new RuntimeException(e);
+SequenceManager manager = new 
SequenceManager((PhoenixStatement)pc.createStatement());
+manager.newSequenceReference(pc.getTenantId(), 
TableName.createNormalized(schemaName, name) , null, 
SequenceValueParseNode.Op.NEXT_VALUE);
--- End diff --

@JamesRTaylor Could you also take a look here to make sure that the method 
is called with right parameters? And is there a chance (and a need) we can 
avoid creating a new "Statement" each time?


---
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.
---

[GitHub] phoenix pull request #220: PHOENIX-3394 Handle SequenceResolving through Con...

[maryannxue]

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

https://github.com/apache/phoenix/pull/220#discussion_r86287255
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/calcite/CalciteIT.java ---
@@ -1315,6 +1315,17 @@ public void initTable() throws Exception {
 {6L, "00A323122312312"},
 {8L, "00A423122312312"}})
 .close();
+
--- End diff --

It's nice to add more test case in CalciteIT, but I'm just curious, why 
aren't existing tests in testSequence() sufficient?


---
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.
---

[GitHub] phoenix pull request #220: PHOENIX-3394 Handle SequenceResolving through Con...

[lomoree]

GitHub user lomoree opened a pull request:

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

PHOENIX-3394 Handle SequenceResolving through ConnectionQueryServices 
interface



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

$ git pull https://github.com/bloomberg/phoenix sequenceresolving

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

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


commit 5ab71200e7d9df42efd3eacbc63383da810cce2e
Author: Eric 
Date:   2016-10-28T22:23:49Z

Sequence resolving initial fix

commit b987c51e0538d498f2c5a15b18d22411a6674134
Author: ERIC LOMORE 
Date:   2016-11-03T02:39:36Z

Clean up & integration tests




---
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] [Updated] (PHOENIX-3394) Handle SequenceResolving through ConnectionQueryServices interface

[Eric Lomore (JIRA)]

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

Eric Lomore updated PHOENIX-3394:
-
Summary: Handle SequenceResolving through ConnectionQueryServices interface 
 (was: Fix getHTable unsupported operation)

> Handle SequenceResolving through ConnectionQueryServices interface
> --
>
> Key: PHOENIX-3394
> URL: https://issues.apache.org/jira/browse/PHOENIX-3394
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
>
> Tons of unit tests have this same stack trace. It appears that this call 
> shouldn't reach ConnectionlessQueryServicesImpl.getTable?
> {code}
> Caused by: java.lang.UnsupportedOperationException
>   at 
> org.apache.phoenix.query.ConnectionlessQueryServicesImpl.getTable(ConnectionlessQueryServicesImpl.java:157)
>   at 
> org.apache.phoenix.query.DelegateConnectionQueryServices.getTable(DelegateConnectionQueryServices.java:70)
>   at 
> org.apache.phoenix.execute.MutationState.getHTable(MutationState.java:360)
>   at 
> org.apache.phoenix.iterate.TableResultIterator.(TableResultIterator.java:101)
>   at 
> org.apache.phoenix.iterate.DefaultTableResultIteratorFactory.newIterator(DefaultTableResultIteratorFactory.java:33)
>   at 
> org.apache.phoenix.iterate.ParallelIterators.submitWork(ParallelIterators.java:104)
>   at 
> org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:871)
>   ... 71 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PHOENIX-3437) Calcite allows CURRENT VALUE to be called on a sequence which has not yet been used

[Eric Lomore (JIRA)]

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

Eric Lomore reassigned PHOENIX-3437:


Assignee: Eric Lomore

> Calcite allows CURRENT VALUE to be called on a sequence which has not yet 
> been used
> ---
>
> Key: PHOENIX-3437
> URL: https://issues.apache.org/jira/browse/PHOENIX-3437
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
>
> Calcite currently returns 0 for a sequence that has CURRENT VALUE called on 
> it before NEXT VALUE is ever called.
> To demonstrate, this sample integration test passes.
> {code}
> connection.createStatement().execute("CREATE SEQUENCE IF NOT EXISTS 
> seq0 START WITH 1 INCREMENT BY 1");
> start(false, 1000f).sql("select CURRENT VALUE FOR seq0, c0 from 
> (values (1), (1)) as t(c0)")
> .explainIs("PhoenixToEnumerableConverter\n" +
> "  
> PhoenixClientProject(EXPR$0=[CURRENT_VALUE('\"SEQ0\"')], C0=[$0])\n" +
> "PhoenixValues(tuples=[[{ 1 }, { 1 }]])\n")
> .resultIs(0, new Object[][]{
> {0L, 1},
> {0L, 1}})
> .close();
> {code}
> But Phoenix's intended behaviour is for this to throw an exception.
> {{SequenceIT.java}}
> {code}
> @Test
> public void testCurrentValueFor() throws Exception {
> ResultSet rs;
> nextConnection();
> conn.createStatement().execute("CREATE SEQUENCE used.nowhere START 
> WITH 2 INCREMENT BY 4");
> nextConnection();
> try {
> rs = conn.createStatement().executeQuery("SELECT CURRENT VALUE 
> FOR used.nowhere FROM SYSTEM.\"SEQUENCE\"");
> rs.next();
> fail();
> } catch (SQLException e) {
> 
> assertEquals(SQLExceptionCode.CANNOT_CALL_CURRENT_BEFORE_NEXT_VALUE.getErrorCode(),
>  e.getErrorCode());
> assertTrue(e.getNextException()==null);
> }
> 
> rs = conn.createStatement().executeQuery("SELECT NEXT VALUE FOR 
> used.nowhere FROM SYSTEM.\"SEQUENCE\"");
> assertTrue(rs.next());
> assertEquals(2, rs.getInt(1));
> rs = conn.createStatement().executeQuery("SELECT CURRENT VALUE FOR 
> used.nowhere FROM SYSTEM.\"SEQUENCE\"");
> assertTrue(rs.next());
> assertEquals(2, rs.getInt(1));
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3437) Calcite allows CURRENT VALUE to be called on a sequence which has not yet been used

[Eric Lomore (JIRA)]

Eric Lomore created PHOENIX-3437:


 Summary: Calcite allows CURRENT VALUE to be called on a sequence 
which has not yet been used
 Key: PHOENIX-3437
 URL: https://issues.apache.org/jira/browse/PHOENIX-3437
 Project: Phoenix
  Issue Type: Sub-task
Reporter: Eric Lomore


Calcite currently returns 0 for a sequence that has CURRENT VALUE called on it 
before NEXT VALUE is ever called.

To demonstrate, this sample integration test passes.
{code}
connection.createStatement().execute("CREATE SEQUENCE IF NOT EXISTS 
seq0 START WITH 1 INCREMENT BY 1");

start(false, 1000f).sql("select CURRENT VALUE FOR seq0, c0 from (values 
(1), (1)) as t(c0)")
.explainIs("PhoenixToEnumerableConverter\n" +
"  
PhoenixClientProject(EXPR$0=[CURRENT_VALUE('\"SEQ0\"')], C0=[$0])\n" +
"PhoenixValues(tuples=[[{ 1 }, { 1 }]])\n")
.resultIs(0, new Object[][]{
{0L, 1},
{0L, 1}})
.close();
{code}

But Phoenix's intended behaviour is for this to throw an exception.
{{SequenceIT.java}}
{code}
@Test
public void testCurrentValueFor() throws Exception {
ResultSet rs;
nextConnection();
conn.createStatement().execute("CREATE SEQUENCE used.nowhere START WITH 
2 INCREMENT BY 4");
nextConnection();
try {
rs = conn.createStatement().executeQuery("SELECT CURRENT VALUE FOR 
used.nowhere FROM SYSTEM.\"SEQUENCE\"");
rs.next();
fail();
} catch (SQLException e) {

assertEquals(SQLExceptionCode.CANNOT_CALL_CURRENT_BEFORE_NEXT_VALUE.getErrorCode(),
 e.getErrorCode());
assertTrue(e.getNextException()==null);
}

rs = conn.createStatement().executeQuery("SELECT NEXT VALUE FOR 
used.nowhere FROM SYSTEM.\"SEQUENCE\"");
assertTrue(rs.next());
assertEquals(2, rs.getInt(1));
rs = conn.createStatement().executeQuery("SELECT CURRENT VALUE FOR 
used.nowhere FROM SYSTEM.\"SEQUENCE\"");
assertTrue(rs.next());
assertEquals(2, rs.getInt(1));
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3435) Upgrade will fail for future releases because of use of timestamp as value for upgrade mutex

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3435:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3435 Upgrade will fail for future releases because of use of (samarth: 
rev e40a2764530b624a58f9d5e577284c34b77283cb)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java


> Upgrade will fail for future releases because of use of timestamp as value 
> for upgrade mutex
> 
>
> Key: PHOENIX-3435
> URL: https://issues.apache.org/jira/browse/PHOENIX-3435
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3435.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3386) PhoenixStorageHandler throws NPE if local tasks executed via child

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3386:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3386 PhoenixStorageHandler throws NPE if local tasks executed (ssa: rev 
41c16a020fcd1cb143675ea17e2d9d3a56750a8a)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/mapreduce/util/PhoenixConfigurationUtil.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/util/PhoenixStorageHandlerUtil.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/PhoenixStorageHandler.java


> PhoenixStorageHandler throws NPE if local tasks executed via child
> --
>
> Key: PHOENIX-3386
> URL: https://issues.apache.org/jira/browse/PHOENIX-3386
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3386.patch
>
>
> By default hive is using hive.exec.submit.local.task.via.child as true. In 
> this case all MR tasks are running in separate processes and in this case NPE 
> is thrown from PhoenixStorageHandler.getTableKeyOfSession. The reason is that 
> in new process the SessionState returns null and method is unable to build 
> key for session. We need to pass session id through jobConf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3423) PhoenixObjectInspector doesn't have information on length of the column.

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3423:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3423 PhoenixObjectInspector doesn't have information on length (ssa: 
rev b477f370c0519d5f5385927d3809fb4a5433a2ec)
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixCharObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixObjectInspectorFactory.java


> PhoenixObjectInspector doesn't have information on length of the column.
> 
>
> Key: PHOENIX-3423
> URL: https://issues.apache.org/jira/browse/PHOENIX-3423
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3423.patch
>
>
> PhoenixObjectInspector doesn't have information on length of the column. this 
> causes making incorrect constant valuesfor char columns in select statement 
> because of padding spaces with max length(255), and get wrong results because 
> of invalid filter conditions.
> ex) column : r_name char(6), 
> hive query : select * from r_name = 'EUROPE',
> phoenix query : select * from r_name = 'EUROPE' (with 
> 249(255 - 6) tailing white spaces)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3408) arithmetic/mathematical operations with Decimal columns failed in Hive with PheonixStorageHandler.

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3408:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3408 arithmetic/mathematical operations with Decimal columns (ssa: rev 
c83d272b565447d39c42a4a8d3b0687bb2b5a16c)
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixObjectInspectorFactory.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixDecimalObjectInspector.java


> arithmetic/mathematical operations with Decimal columns failed in Hive with 
> PheonixStorageHandler.
> --
>
> Key: PHOENIX-3408
> URL: https://issues.apache.org/jira/browse/PHOENIX-3408
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3408.patch
>
>
> PhoenixDecimalObjectInspector doesn't hold decimal type information (holds 
> default max precision/scale (38/10)), so it doesn't make correct object that 
> fits into the schema. this causes incorrect results for decimal operations 
> (+, -, *, -, functions...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3387) Hive PhoenixStorageHandler fails with join on numeric fields

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3387:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3387 Hive PhoenixStorageHandler fails with join on numeric (ssa: rev 
86f51602b59100e67b0f87b247a07bdec6dfcb17)
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixDoubleObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixIntObjectInspector.java
* (edit) phoenix-hive/src/it/java/org/apache/phoenix/hive/HiveTestUtil.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixByteObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixFloatObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixLongObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixDecimalObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixBooleanObjectInspector.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/objectinspector/PhoenixShortObjectInspector.java


> Hive PhoenixStorageHandler fails with join on numeric fields
> 
>
> Key: PHOENIX-3387
> URL: https://issues.apache.org/jira/browse/PHOENIX-3387
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3387.patch
>
>
> If condition for join is using numeric field, the MR job fails with class 
> cast exception. The reason is that all object inspectors for numeric types 
> doesn't implement getPrimitiveWritableObject method. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3422) PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) column type.

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3422:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3422 PhoenixQueryBuilder doesn't make value string correctly for (ssa: 
rev a37403cd9ff5c9c6913394fcbb18c97a6a267675)
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/util/PhoenixStorageHandlerUtil.java
* (add) 
phoenix-hive/src/test/java/org/apache/phoenix/hive/query/PhoenixQueryBuilderTest.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/query/PhoenixQueryBuilder.java
* (edit) phoenix-hive/pom.xml


> PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) 
> column type.
> ---
>
> Key: PHOENIX-3422
> URL: https://issues.apache.org/jira/browse/PHOENIX-3422
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3422.patch
>
>
> with a query that includes (v)char column type expression in where clause , a 
> query builder can't make a value string that is wrapped with single quote 
> character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3434) Avoid creating new Configuration in ClientAggregatePlan to improve performance

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3434:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3434 Avoid creating new Configuration in ClientAggregatePlan to 
(jamestaylor: rev cb59b2e5a144bc8075f897e6a91bfd388fb8cc44)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/aggregator/ServerAggregators.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/DelegateConnectionQueryServices.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientAggregatePlan.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/function/SingleAggregateFunction.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionlessQueryServicesImpl.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServices.java


> Avoid creating new Configuration in ClientAggregatePlan to improve performance
> --
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch, PHOENIX-3434_addendum1.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3416) Memory leak in PhoenixStorageHandler

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3416:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1470 (See 
[https://builds.apache.org/job/Phoenix-master/1470/])
PHOENIX-3416 Memory leak in PhoenixStorageHandler (ssa: rev 
e1afbcce546b822e81f7fa0fc37e0de6fe5b8d0c)
* (delete) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/ppd/PhoenixPredicateDecomposerManager.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/ppd/PhoenixPredicateDecomposer.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/mapreduce/PhoenixInputFormat.java
* (edit) 
phoenix-hive/src/main/java/org/apache/phoenix/hive/PhoenixStorageHandler.java


> Memory leak in PhoenixStorageHandler
> 
>
> Key: PHOENIX-3416
> URL: https://issues.apache.org/jira/browse/PHOENIX-3416
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3416.patch
>
>
> when executing EXPLAIN query, hive doesn't execute Tasks that get and remove 
> PhoenixPredicateDecomposer from PREDICATE_DECOMPOSER_MAP. so, all predicate 
> decomposers made from the explain query exists forever in the decomposer map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[chenglei (JIRA)]

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

chenglei commented on PHOENIX-3208:
---

[~jamestaylor],think you for the review.

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
>Assignee: chenglei
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3355) Register Phoenix built-in functions as Calcite functions

[Maryann Xue (JIRA)]

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

Maryann Xue commented on PHOENIX-3355:
--

Two things:
1. The reason why ToDateFunction takes two extra arguments aside from the list 
is that at "parse" time the last two parameters have been pre-processed and 
thus have become two independent arguments. I think in this case it would make 
more sense to change the constructor signature back to taking a list only and 
to process the last two arguments within the constructor. This would avoid 
having to have special handling for each individual function such as 
ToDateFunction. Meanwhile, in order to process the last two arguments, 
"dateFormat" and "timeZoneId", we need a StatementContext, or essentially the 
PhoenixConnection's properties. So I think we can allow two types of signatures 
for Function constructors:
a) XXXFunction(List)
b) XXXFunction(List, StatementContext)
Then it would only require an if-else in {{constructUDFFunction()}}.
 
2. Optimally we should have a StatementContext object in 
{{PhoenixImplementorImpl}} so that it can be used by the function translation. 
It has been a question there for a while, but we'll figure it out.
 
[~lomoree] and [~jamestaylor], what do you think about (1)? Can all built-in 
functions be solved that way?

> Register Phoenix built-in functions as Calcite functions
> 
>
> Key: PHOENIX-3355
> URL: https://issues.apache.org/jira/browse/PHOENIX-3355
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Eric Lomore
>  Labels: calcite
> Attachments: PHOENIX-3355.wip, PHOENIX-3355.wip2
>
>
> We should register all Phoenix built-in functions that don't exist in Calcite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE] Release of Apache Phoenix 4.9.0 RC1

[James Taylor]

Hello Everyone,

This is a call for a vote on Apache Phoenix 4.9.0 RC1. This is the next
minor release of Phoenix 4, compatible with Apache HBase 0.98, 1.1 & 1.2.
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-3433 and PHOENIX-3432 which have now been fixed.

This release has feature parity with supported HBase versions and includes
the following improvements:
- Atomic upsert through new ON DUPLICATE KEY syntax [1]
- Support for DEFAULT declaration in DDL statements [2]
- Specify guidepost width per table [3]
- ~40 bugs resolved

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

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

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

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=eedb2b4d94c86b50cd0ecd249c3f17573eaf9e4a
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.9.0-HBase-0.98-rc1
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=15659904b5a744eeb6008d3811207c95551e7ef2
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.9.0-HBase-1.1-rc1
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=a6c9024c2534a953eb46ea21d20a06fe155d780a
https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.9.0-HBase-1.2-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-6
[2] https://issues.apache.org/jira/browse/PHOENIX-476
[3] https://issues.apache.org/jira/browse/PHOENIX-2675

[jira] [Commented] (PHOENIX-3434) Avoid creating new Configuration in ClientAggregatePlan to improve performance

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3434:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1469 (See 
[https://builds.apache.org/job/Phoenix-master/1469/])
PHOENIX-3434 Avoid deserialization of ServerAggregators in (jamestaylor: rev 
268c395e63df2ee6b32fd23cfcb365439b2bfb93)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/aggregator/Aggregators.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientAggregatePlan.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/expression/aggregator/ServerAggregators.java


> Avoid creating new Configuration in ClientAggregatePlan to improve performance
> --
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch, PHOENIX-3434_addendum1.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in snapshot name

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3432:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1469 (See 
[https://builds.apache.org/job/Phoenix-master/1469/])
PHOENIX-3432 Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal (samarth: 
rev d7b821a7bcc4772f30ac01716415bcd47f211b18)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java


> Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in 
> snapshot name
> ---
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> 

[jira] [Commented] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3208:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1469 (See 
[https://builds.apache.org/job/Phoenix-master/1469/])
PHOENIX-3208 MutationState.toMutations method would throw a exception if 
(jamestaylor: rev 184194775aa1aa79a94cc93610667bd6124f059c)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/execute/MutationState.java
* (edit) 
phoenix-core/src/test/java/org/apache/phoenix/execute/MutationStateTest.java


> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
>Assignee: chenglei
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PHOENIX-3118) Increase default value of hbase.client.scanner.max.result.size

[James Taylor (JIRA)]

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

James Taylor resolved PHOENIX-3118.
---
Resolution: Won't Fix

> Increase default value of hbase.client.scanner.max.result.size
> --
>
> Key: PHOENIX-3118
> URL: https://issues.apache.org/jira/browse/PHOENIX-3118
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
> Fix For: 4.10.0, 4.8.3
>
>
> See parent JIRA for a discussion on how to handle partial scan results. An 
> easy workaround would be to increase the 
> {{hbase.client.scanner.max.result.size}} above the default 2MB limit. In 
> combination with this, we could detect in BaseScannerRegionObserver.nextRaw() 
> if partial results are being returned and throw an exception. Silently 
> ignoring this is bad because it can lead to incorrect query results as 
> demonstrated by the parent JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[Andrew Purtell]

Go ahead lars :-)

On Wed, Nov 2, 2016 at 3:37 PM,  wrote:

> Great. 14 fixes in a patch release. That's a healthy number.
> Andy, didn't react to your earlier offer... Did you want to do the 4.8.2
> release? Fine either way.
>
> -- Lars
>   From: Samarth Jain 
>  To: dev ; la...@apache.org
>  Sent: Wednesday, November 2, 2016 3:31 PM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> Changes in PHOENIX-3432 were committed as part of PHOENIX-3436.
> On Wed, Nov 2, 2016 at 3:29 PM,  wrote:
>
> Need to wait PHOENIX-3432 in both branches.
>
>   From: "la...@apache.org" 
>  To: "dev@phoenix.apache.org" 
>  Sent: Wednesday, November 2, 2016 3:27 PM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> I'll clean up Jira for 4.8.2 and spin the RCs. Today and/or early tomorrow.
>
>   From: James Taylor 
>  To: "dev@phoenix.apache.org" 
> Cc: lars hofhansl 
>  Sent: Wednesday, November 2, 2016 3:00 PM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> I'm in support of 4.8.2. I was just pointing out that we've already started
> the release process for 4.9 as your prior email seemed to indicate that
> perhaps you weren't aware of that.
>
> On Wednesday, November 2, 2016, Andrew Purtell 
> wrote:
>
> > There was an earlier discussion here regarding supporting multiple code
> > lines. There seemed to be support for that. That implies maintenance of
> at
> > least one code line prior to the most recent, no? Or otherwise nothing
> has
> > changed, leaving all users who can't use or don't want the bleeding edge
> to
> > patch for themselves.
> >
> > And, especially because 4.8.x won't work with 1.2 at all, I think a
> release
> > that fixes that problem before moving on from 4.8 is a responsible thing
> to
> > do.
> >
> >
> > On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > > wrote:
> >
> > > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > > now. Second RC will be up today.
> > >
> > > On Wednesday, November 2, 2016, Andrew Purtell  > >
> > > wrote:
> > >
> > > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> > before
> > > > moving on to 4.9 and up.
> > > >
> > > >
> > > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > > wrote:
> > > >
> > > > > Was going to do it this week. Then again, since 4.9.0 does not
> > include
> > > > the
> > > > > column encoding I was less enthused about it.If we think we want a
> > > 4.8.2
> > > > > I'll spin an RC today.
> > > > > -- Lars
> > > > >
> > > > >  From: Andrew Purtell 
> > >
> > > > >  To: "dev@phoenix.apache.org  " <
> > dev@phoenix.apache.org 
> > > > >
> > > > > Cc: lars hofhansl  >
> > > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > > >
> > > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> > releases
> > > > > with a fixed version of it. I don't think we can ever fully
> > understand
> > > > the
> > > > > version usage patterns of our users. I've seen folks write in to
> > HBase
> > > > > lists using 4 year old releases for unfathomable reasons.
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> > jamestay...@apache.org 
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1
> who
> > > > would
> > > > > > not want to upgrade to 4.9.0? We're in the voting stage for a
> 4.9.0
> > > > which
> > > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > > usual)
> > > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move
> to
> > > > 4.9.0.
> > > > > >
> > > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > > users
> > > > > on
> > > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > > >
> > > > > > Thanks,
> > > > > > James
> > > > > >
> > > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> > apurt...@apache.org 
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > > Phoenix
> > > > > > > release.
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > > jamestay...@apache.org  >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > > 10/31)
> > > > > > with
> > > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > > PHOENIX-6
> > > > > > > > (atomic insert/update).  If it's too much 

Re: 4.8.2 and/or 4.9.0

[larsh]

Great. 14 fixes in a patch release. That's a healthy number.
Andy, didn't react to your earlier offer... Did you want to do the 4.8.2 
release? Fine either way.

-- Lars
  From: Samarth Jain 
 To: dev ; la...@apache.org 
 Sent: Wednesday, November 2, 2016 3:31 PM
 Subject: Re: 4.8.2 and/or 4.9.0
   
Changes in PHOENIX-3432 were committed as part of PHOENIX-3436. 
On Wed, Nov 2, 2016 at 3:29 PM,  wrote:

Need to wait PHOENIX-3432 in both branches.

      From: "la...@apache.org" 
 To: "dev@phoenix.apache.org" 
 Sent: Wednesday, November 2, 2016 3:27 PM
 Subject: Re: 4.8.2 and/or 4.9.0

I'll clean up Jira for 4.8.2 and spin the RCs. Today and/or early tomorrow.

      From: James Taylor 
 To: "dev@phoenix.apache.org" 
Cc: lars hofhansl 
 Sent: Wednesday, November 2, 2016 3:00 PM
 Subject: Re: 4.8.2 and/or 4.9.0
 
I'm in support of 4.8.2. I was just pointing out that we've already started
the release process for 4.9 as your prior email seemed to indicate that
perhaps you weren't aware of that.

On Wednesday, November 2, 2016, Andrew Purtell  wrote:

> There was an earlier discussion here regarding supporting multiple code
> lines. There seemed to be support for that. That implies maintenance of at
> least one code line prior to the most recent, no? Or otherwise nothing has
> changed, leaving all users who can't use or don't want the bleeding edge to
> patch for themselves.
>
> And, especially because 4.8.x won't work with 1.2 at all, I think a release
> that fixes that problem before moving on from 4.8 is a responsible thing to
> do.
>
>
> On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > wrote:
>
> > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > now. Second RC will be up today.
> >
> > On Wednesday, November 2, 2016, Andrew Purtell  >
> > wrote:
> >
> > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> before
> > > moving on to 4.9 and up.
> > >
> > >
> > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > wrote:
> > >
> > > > Was going to do it this week. Then again, since 4.9.0 does not
> include
> > > the
> > > > column encoding I was less enthused about it.If we think we want a
> > 4.8.2
> > > > I'll spin an RC today.
> > > > -- Lars
> > > >
> > > >      From: Andrew Purtell 
> >
> > > >  To: "dev@phoenix.apache.org  " <
> dev@phoenix.apache.org 
> > > >
> > > > Cc: lars hofhansl  >
> > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > >
> > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> releases
> > > > with a fixed version of it. I don't think we can ever fully
> understand
> > > the
> > > > version usage patterns of our users. I've seen folks write in to
> HBase
> > > > lists using 4 year old releases for unfathomable reasons.
> > > >
> > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> jamestay...@apache.org 
> > > >
> > > > wrote:
> > > >
> > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > > would
> > > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > > which
> > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > usual)
> > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > > 4.9.0.
> > > > >
> > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > users
> > > > on
> > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > >
> > > > > Thanks,
> > > > > James
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> apurt...@apache.org 
> > > >
> > > > > wrote:
> > > > >
> > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > Phoenix
> > > > > > release.
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > jamestay...@apache.org  >
> > > > > > wrote:
> > > > > >
> > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > 10/31)
> > > > > with
> > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > PHOENIX-6
> > > > > > > (atomic insert/update).  If it's too much much for you to do
> both
> > > > 4.8.2
> > > > > > and
> > > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  
> > >
> > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > > we have 20 jiras against 4.8.2 

[jira] [Resolved] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in snapshot name

[Samarth Jain (JIRA)]

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

Samarth Jain resolved PHOENIX-3432.
---
Resolution: Fixed

> Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in 
> snapshot name
> ---
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> 

Re: 4.8.2 and/or 4.9.0

[Samarth Jain]

Changes in PHOENIX-3432 were committed as part of PHOENIX-3436.

On Wed, Nov 2, 2016 at 3:29 PM,  wrote:

> Need to wait PHOENIX-3432 in both branches.
>
>   From: "la...@apache.org" 
>  To: "dev@phoenix.apache.org" 
>  Sent: Wednesday, November 2, 2016 3:27 PM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> I'll clean up Jira for 4.8.2 and spin the RCs. Today and/or early tomorrow.
>
>   From: James Taylor 
>  To: "dev@phoenix.apache.org" 
> Cc: lars hofhansl 
>  Sent: Wednesday, November 2, 2016 3:00 PM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> I'm in support of 4.8.2. I was just pointing out that we've already started
> the release process for 4.9 as your prior email seemed to indicate that
> perhaps you weren't aware of that.
>
> On Wednesday, November 2, 2016, Andrew Purtell 
> wrote:
>
> > There was an earlier discussion here regarding supporting multiple code
> > lines. There seemed to be support for that. That implies maintenance of
> at
> > least one code line prior to the most recent, no? Or otherwise nothing
> has
> > changed, leaving all users who can't use or don't want the bleeding edge
> to
> > patch for themselves.
> >
> > And, especially because 4.8.x won't work with 1.2 at all, I think a
> release
> > that fixes that problem before moving on from 4.8 is a responsible thing
> to
> > do.
> >
> >
> > On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > > wrote:
> >
> > > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > > now. Second RC will be up today.
> > >
> > > On Wednesday, November 2, 2016, Andrew Purtell  > >
> > > wrote:
> > >
> > > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> > before
> > > > moving on to 4.9 and up.
> > > >
> > > >
> > > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > > wrote:
> > > >
> > > > > Was going to do it this week. Then again, since 4.9.0 does not
> > include
> > > > the
> > > > > column encoding I was less enthused about it.If we think we want a
> > > 4.8.2
> > > > > I'll spin an RC today.
> > > > > -- Lars
> > > > >
> > > > >  From: Andrew Purtell 
> > >
> > > > >  To: "dev@phoenix.apache.org  " <
> > dev@phoenix.apache.org 
> > > > >
> > > > > Cc: lars hofhansl  >
> > > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > > >
> > > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> > releases
> > > > > with a fixed version of it. I don't think we can ever fully
> > understand
> > > > the
> > > > > version usage patterns of our users. I've seen folks write in to
> > HBase
> > > > > lists using 4 year old releases for unfathomable reasons.
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> > jamestay...@apache.org 
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1
> who
> > > > would
> > > > > > not want to upgrade to 4.9.0? We're in the voting stage for a
> 4.9.0
> > > > which
> > > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > > usual)
> > > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move
> to
> > > > 4.9.0.
> > > > > >
> > > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > > users
> > > > > on
> > > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > > >
> > > > > > Thanks,
> > > > > > James
> > > > > >
> > > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> > apurt...@apache.org 
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > > Phoenix
> > > > > > > release.
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > > jamestay...@apache.org  >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > > 10/31)
> > > > > > with
> > > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > > PHOENIX-6
> > > > > > > > (atomic insert/update).  If it's too much much for you to do
> > both
> > > > > 4.8.2
> > > > > > > and
> > > > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > > > >
> > > > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  > 
> > > >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Hi All,
> > > > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > > > enough
> > > > > > ...
> > > > > > > > and
> > 

Re: 4.8.2 and/or 4.9.0

[larsh]

Need to wait PHOENIX-3432 in both branches.

  From: "la...@apache.org" 
 To: "dev@phoenix.apache.org"  
 Sent: Wednesday, November 2, 2016 3:27 PM
 Subject: Re: 4.8.2 and/or 4.9.0
   
I'll clean up Jira for 4.8.2 and spin the RCs. Today and/or early tomorrow.

      From: James Taylor 
 To: "dev@phoenix.apache.org"  
Cc: lars hofhansl 
 Sent: Wednesday, November 2, 2016 3:00 PM
 Subject: Re: 4.8.2 and/or 4.9.0
  
I'm in support of 4.8.2. I was just pointing out that we've already started
the release process for 4.9 as your prior email seemed to indicate that
perhaps you weren't aware of that.

On Wednesday, November 2, 2016, Andrew Purtell  wrote:

> There was an earlier discussion here regarding supporting multiple code
> lines. There seemed to be support for that. That implies maintenance of at
> least one code line prior to the most recent, no? Or otherwise nothing has
> changed, leaving all users who can't use or don't want the bleeding edge to
> patch for themselves.
>
> And, especially because 4.8.x won't work with 1.2 at all, I think a release
> that fixes that problem before moving on from 4.8 is a responsible thing to
> do.
>
>
> On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > wrote:
>
> > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > now. Second RC will be up today.
> >
> > On Wednesday, November 2, 2016, Andrew Purtell  >
> > wrote:
> >
> > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> before
> > > moving on to 4.9 and up.
> > >
> > >
> > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > wrote:
> > >
> > > > Was going to do it this week. Then again, since 4.9.0 does not
> include
> > > the
> > > > column encoding I was less enthused about it.If we think we want a
> > 4.8.2
> > > > I'll spin an RC today.
> > > > -- Lars
> > > >
> > > >      From: Andrew Purtell 
> >
> > > >  To: "dev@phoenix.apache.org  " <
> dev@phoenix.apache.org 
> > > >
> > > > Cc: lars hofhansl  >
> > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > >
> > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> releases
> > > > with a fixed version of it. I don't think we can ever fully
> understand
> > > the
> > > > version usage patterns of our users. I've seen folks write in to
> HBase
> > > > lists using 4 year old releases for unfathomable reasons.
> > > >
> > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> jamestay...@apache.org 
> > > >
> > > > wrote:
> > > >
> > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > > would
> > > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > > which
> > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > usual)
> > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > > 4.9.0.
> > > > >
> > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > users
> > > > on
> > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > >
> > > > > Thanks,
> > > > > James
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> apurt...@apache.org 
> > > >
> > > > > wrote:
> > > > >
> > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > Phoenix
> > > > > > release.
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > jamestay...@apache.org  >
> > > > > > wrote:
> > > > > >
> > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > 10/31)
> > > > > with
> > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > PHOENIX-6
> > > > > > > (atomic insert/update).  If it's too much much for you to do
> both
> > > > 4.8.2
> > > > > > and
> > > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  
> > >
> > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > > enough
> > > > > ...
> > > > > > > and
> > > > > > > > over 200 against 4.9.0.
> > > > > > > > I think we should start keeping stable branches for longer.As
> > > > before
> > > > > > I'll
> > > > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > > > vastly
> > > > > > > > different opinions.
> > > > > > > >
> > > > > > > > -- Lars
> > > > > > > >
> > > 

Re: 4.8.2 and/or 4.9.0

[larsh]

I'll clean up Jira for 4.8.2 and spin the RCs. Today and/or early tomorrow.

  From: James Taylor 
 To: "dev@phoenix.apache.org"  
Cc: lars hofhansl 
 Sent: Wednesday, November 2, 2016 3:00 PM
 Subject: Re: 4.8.2 and/or 4.9.0
   
I'm in support of 4.8.2. I was just pointing out that we've already started
the release process for 4.9 as your prior email seemed to indicate that
perhaps you weren't aware of that.

On Wednesday, November 2, 2016, Andrew Purtell  wrote:

> There was an earlier discussion here regarding supporting multiple code
> lines. There seemed to be support for that. That implies maintenance of at
> least one code line prior to the most recent, no? Or otherwise nothing has
> changed, leaving all users who can't use or don't want the bleeding edge to
> patch for themselves.
>
> And, especially because 4.8.x won't work with 1.2 at all, I think a release
> that fixes that problem before moving on from 4.8 is a responsible thing to
> do.
>
>
> On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > wrote:
>
> > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > now. Second RC will be up today.
> >
> > On Wednesday, November 2, 2016, Andrew Purtell  >
> > wrote:
> >
> > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> before
> > > moving on to 4.9 and up.
> > >
> > >
> > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > wrote:
> > >
> > > > Was going to do it this week. Then again, since 4.9.0 does not
> include
> > > the
> > > > column encoding I was less enthused about it.If we think we want a
> > 4.8.2
> > > > I'll spin an RC today.
> > > > -- Lars
> > > >
> > > >      From: Andrew Purtell 
> >
> > > >  To: "dev@phoenix.apache.org  " <
> dev@phoenix.apache.org 
> > > >
> > > > Cc: lars hofhansl  >
> > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > >
> > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> releases
> > > > with a fixed version of it. I don't think we can ever fully
> understand
> > > the
> > > > version usage patterns of our users. I've seen folks write in to
> HBase
> > > > lists using 4 year old releases for unfathomable reasons.
> > > >
> > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> jamestay...@apache.org 
> > > >
> > > > wrote:
> > > >
> > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > > would
> > > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > > which
> > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > usual)
> > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > > 4.9.0.
> > > > >
> > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > users
> > > > on
> > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > >
> > > > > Thanks,
> > > > > James
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> apurt...@apache.org 
> > > >
> > > > > wrote:
> > > > >
> > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > Phoenix
> > > > > > release.
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > jamestay...@apache.org  >
> > > > > > wrote:
> > > > > >
> > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > 10/31)
> > > > > with
> > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > PHOENIX-6
> > > > > > > (atomic insert/update).  If it's too much much for you to do
> both
> > > > 4.8.2
> > > > > > and
> > > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  
> > >
> > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > > enough
> > > > > ...
> > > > > > > and
> > > > > > > > over 200 against 4.9.0.
> > > > > > > > I think we should start keeping stable branches for longer.As
> > > > before
> > > > > > I'll
> > > > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > > > vastly
> > > > > > > > different opinions.
> > > > > > > >
> > > > > > > > -- Lars
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > >    - Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back. -
> Piet
> > > > Hein
> > 

[jira] [Resolved] (PHOENIX-1351) LIKE is not working when the column value contains LINE FEED

[James Taylor (JIRA)]

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

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

Duplicate of PHOENIX-2645

> LIKE is not working when the column value contains LINE FEED
> 
>
> Key: PHOENIX-1351
> URL: https://issues.apache.org/jira/browse/PHOENIX-1351
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Tao Lu
>
> select * from t where content like '%xyx%';
> Above SQL is not working when "content" contains any LINE FEED (\n). It 
> always return empty result set. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3355) Register Phoenix built-in functions as Calcite functions

[Eric Lomore (JIRA)]

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

Eric Lomore commented on PHOENIX-3355:
--

[~maryannxue], I am running into a few more issues, would you mind taking a 
look? 

Functions with the expected constructor with parameter List.class now work as 
expected. But those that do not cannot instantiate properly.

{code}
private void constructUDFFunction() throws IOException {
Constructor constructor = clazz.getConstructor(List.class);
udfFunction = 
(ScalarFunction)constructor.newInstance(this.children);
} {code}


For example, ToDateFunction stacktrace:
{code}Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodException: 
org.apache.phoenix.expression.function.ToDateFunction.(java.util.List)
at 
org.apache.phoenix.expression.function.UDFExpression.constructUDFFunction(UDFExpression.java:170)
at 
org.apache.phoenix.expression.function.UDFExpression.(UDFExpression.java:72)
at 
org.apache.phoenix.calcite.CalciteUtils$19.newExpression(CalciteUtils.java:788)
at 
org.apache.phoenix.calcite.CalciteUtils.convertChildren(CalciteUtils.java:1006)
at 
org.apache.phoenix.calcite.CalciteUtils.access$000(CalciteUtils.java:138)
at 
org.apache.phoenix.calcite.CalciteUtils$3.newExpression(CalciteUtils.java:324)
at 
org.apache.phoenix.calcite.CalciteUtils.toExpression(CalciteUtils.java:1071)
at 
org.apache.phoenix.calcite.rel.PhoenixTableScan.(PhoenixTableScan.java:153)
at 
org.apache.phoenix.calcite.rel.PhoenixTableScan.create(PhoenixTableScan.java:94)
at 
org.apache.phoenix.calcite.rules.PhoenixFilterScanMergeRule.onMatch(PhoenixFilterScanMergeRule.java:46)
at 
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
... 47 more
Caused by: java.lang.NoSuchMethodException: 
org.apache.phoenix.expression.function.ToDateFunction.(java.util.List)
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getConstructor(Class.java:1825)
at 
org.apache.phoenix.expression.function.UDFExpression.constructUDFFunction(UDFExpression.java:165)
... 57 more
{code}

The only uniform way to instantiate on the phoenix side is through the parse 
node create function (ex. ToDateParseNode.create()).

{code}
public FunctionExpression create(List children, StatementContext 
context) throws SQLException {
 // creates ExampleFunction
} {code}

We would still have to register PhoenixScalarFunction using the class name of a 
function, but in constructUDFFunction() it would need to refer to the 
ParseNode. Unfortunately, I'm a bit stuck on where to go from here. We would be 
using a parse node but not at parse time which introduces some complications. 
See my latest commit here:
https://github.com/bloomberg/phoenix/commit/24652257e1f2c039b62288387d911c47e30399c6
You'll notice StatementContext is null which cannot be the case, but I don't 
see a way around this.

> Register Phoenix built-in functions as Calcite functions
> 
>
> Key: PHOENIX-3355
> URL: https://issues.apache.org/jira/browse/PHOENIX-3355
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Eric Lomore
>  Labels: calcite
> Attachments: PHOENIX-3355.wip, PHOENIX-3355.wip2
>
>
> We should register all Phoenix built-in functions that don't exist in Calcite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[James Taylor]

I'm in support of 4.8.2. I was just pointing out that we've already started
the release process for 4.9 as your prior email seemed to indicate that
perhaps you weren't aware of that.

On Wednesday, November 2, 2016, Andrew Purtell  wrote:

> There was an earlier discussion here regarding supporting multiple code
> lines. There seemed to be support for that. That implies maintenance of at
> least one code line prior to the most recent, no? Or otherwise nothing has
> changed, leaving all users who can't use or don't want the bleeding edge to
> patch for themselves.
>
> And, especially because 4.8.x won't work with 1.2 at all, I think a release
> that fixes that problem before moving on from 4.8 is a responsible thing to
> do.
>
>
> On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  > wrote:
>
> > Sounds good, except we've already moved on to 4.9 as we're voting on it
> > now. Second RC will be up today.
> >
> > On Wednesday, November 2, 2016, Andrew Purtell  >
> > wrote:
> >
> > > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+
> before
> > > moving on to 4.9 and up.
> > >
> > >
> > > On Wed, Nov 2, 2016 at 2:00 PM, 
> > wrote:
> > >
> > > > Was going to do it this week. Then again, since 4.9.0 does not
> include
> > > the
> > > > column encoding I was less enthused about it.If we think we want a
> > 4.8.2
> > > > I'll spin an RC today.
> > > > -- Lars
> > > >
> > > >   From: Andrew Purtell 
> >
> > > >  To: "dev@phoenix.apache.org  " <
> dev@phoenix.apache.org 
> > > >
> > > > Cc: lars hofhansl  >
> > > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > > >  Subject: Re: 4.8.2 and/or 4.9.0
> > > >
> > > > Right, I think we should address PHOENIX-3407 in current 4.8.x
> releases
> > > > with a fixed version of it. I don't think we can ever fully
> understand
> > > the
> > > > version usage patterns of our users. I've seen folks write in to
> HBase
> > > > lists using 4 year old releases for unfathomable reasons.
> > > >
> > > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor <
> jamestay...@apache.org 
> > > >
> > > > wrote:
> > > >
> > > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > > would
> > > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > > which
> > > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> > usual)
> > > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > > 4.9.0.
> > > > >
> > > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> > users
> > > > on
> > > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > > >
> > > > > Thanks,
> > > > > James
> > > > >
> > > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell <
> apurt...@apache.org 
> > > >
> > > > > wrote:
> > > > >
> > > > > > Need help with making a 4.8.2? I could try my hand at making a
> > > Phoenix
> > > > > > release.
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > > jamestay...@apache.org  >
> > > > > > wrote:
> > > > > >
> > > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > > 10/31)
> > > > > with
> > > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > > PHOENIX-6
> > > > > > > (atomic insert/update).  If it's too much much for you to do
> both
> > > > 4.8.2
> > > > > > and
> > > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > > >
> > > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  
> > >
> > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > > enough
> > > > > ...
> > > > > > > and
> > > > > > > > over 200 against 4.9.0.
> > > > > > > > I think we should start keeping stable branches for longer.As
> > > > before
> > > > > > I'll
> > > > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > > > vastly
> > > > > > > > different opinions.
> > > > > > > >
> > > > > > > > -- Lars
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > >- Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back. -
> Piet
> > > > Hein
> > > > > > (via Tom White)
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >   - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > 

Re: 4.8.2 and/or 4.9.0

[Andrew Purtell]

There was an earlier discussion here regarding supporting multiple code
lines. There seemed to be support for that. That implies maintenance of at
least one code line prior to the most recent, no? Or otherwise nothing has
changed, leaving all users who can't use or don't want the bleeding edge to
patch for themselves.

And, especially because 4.8.x won't work with 1.2 at all, I think a release
that fixes that problem before moving on from 4.8 is a responsible thing to
do.


On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  wrote:

> Sounds good, except we've already moved on to 4.9 as we're voting on it
> now. Second RC will be up today.
>
> On Wednesday, November 2, 2016, Andrew Purtell 
> wrote:
>
> > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+ before
> > moving on to 4.9 and up.
> >
> >
> > On Wed, Nov 2, 2016 at 2:00 PM, > wrote:
> >
> > > Was going to do it this week. Then again, since 4.9.0 does not include
> > the
> > > column encoding I was less enthused about it.If we think we want a
> 4.8.2
> > > I'll spin an RC today.
> > > -- Lars
> > >
> > >   From: Andrew Purtell >
> > >  To: "dev@phoenix.apache.org "  > >
> > > Cc: lars hofhansl >
> > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > >  Subject: Re: 4.8.2 and/or 4.9.0
> > >
> > > Right, I think we should address PHOENIX-3407 in current 4.8.x releases
> > > with a fixed version of it. I don't think we can ever fully understand
> > the
> > > version usage patterns of our users. I've seen folks write in to HBase
> > > lists using 4 year old releases for unfathomable reasons.
> > >
> > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor  > >
> > > wrote:
> > >
> > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > would
> > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > which
> > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> usual)
> > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > 4.9.0.
> > > >
> > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> users
> > > on
> > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > >
> > > > Thanks,
> > > > James
> > > >
> > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell  > >
> > > > wrote:
> > > >
> > > > > Need help with making a 4.8.2? I could try my hand at making a
> > Phoenix
> > > > > release.
> > > > >
> > > > >
> > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > jamestay...@apache.org >
> > > > > wrote:
> > > > >
> > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > 10/31)
> > > > with
> > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > PHOENIX-6
> > > > > > (atomic insert/update).  If it's too much much for you to do both
> > > 4.8.2
> > > > > and
> > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  >
> > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > enough
> > > > ...
> > > > > > and
> > > > > > > over 200 against 4.9.0.
> > > > > > > I think we should start keeping stable branches for longer.As
> > > before
> > > > > I'll
> > > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > > vastly
> > > > > > > different opinions.
> > > > > > >
> > > > > > > -- Lars
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >- Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >   - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 4.8.2 and/or 4.9.0

[Samarth Jain]

I am done porting changes as part of
https://issues.apache.org/jira/browse/PHOENIX-3436.

On Wed, Nov 2, 2016 at 2:34 PM, James Taylor  wrote:

> Sounds good, except we've already moved on to 4.9 as we're voting on it
> now. Second RC will be up today.
>
> On Wednesday, November 2, 2016, Andrew Purtell 
> wrote:
>
> > Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+ before
> > moving on to 4.9 and up.
> >
> >
> > On Wed, Nov 2, 2016 at 2:00 PM, > wrote:
> >
> > > Was going to do it this week. Then again, since 4.9.0 does not include
> > the
> > > column encoding I was less enthused about it.If we think we want a
> 4.8.2
> > > I'll spin an RC today.
> > > -- Lars
> > >
> > >   From: Andrew Purtell >
> > >  To: "dev@phoenix.apache.org "  > >
> > > Cc: lars hofhansl >
> > >  Sent: Wednesday, November 2, 2016 11:41 AM
> > >  Subject: Re: 4.8.2 and/or 4.9.0
> > >
> > > Right, I think we should address PHOENIX-3407 in current 4.8.x releases
> > > with a fixed version of it. I don't think we can ever fully understand
> > the
> > > version usage patterns of our users. I've seen folks write in to HBase
> > > lists using 4 year old releases for unfathomable reasons.
> > >
> > > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor  > >
> > > wrote:
> > >
> > > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> > would
> > > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> > which
> > > > has all the fixes in 4.8 branch (and more) and is compatible (as
> usual)
> > > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> > 4.9.0.
> > > >
> > > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465),
> users
> > > on
> > > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > > >
> > > > Thanks,
> > > > James
> > > >
> > > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell  > >
> > > > wrote:
> > > >
> > > > > Need help with making a 4.8.2? I could try my hand at making a
> > Phoenix
> > > > > release.
> > > > >
> > > > >
> > > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> > jamestay...@apache.org >
> > > > > wrote:
> > > > >
> > > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> > 10/31)
> > > > with
> > > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > > PHOENIX-6
> > > > > > (atomic insert/update).  If it's too much much for you to do both
> > > 4.8.2
> > > > > and
> > > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > > >
> > > > > > On Sat, Oct 15, 2016 at 6:42 PM,  >
> > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > > we have 20 jiras against 4.8.2 some of which seem important
> > enough
> > > > ...
> > > > > > and
> > > > > > > over 200 against 4.9.0.
> > > > > > > I think we should start keeping stable branches for longer.As
> > > before
> > > > > I'll
> > > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > > vastly
> > > > > > > different opinions.
> > > > > > >
> > > > > > > -- Lars
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >- Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >   - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

[jira] [Resolved] (PHOENIX-3436) Port snapshot and upgrade mutex fixes to 4.8 branches

[Samarth Jain (JIRA)]

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

Samarth Jain resolved PHOENIX-3436.
---
   Resolution: Fixed
Fix Version/s: 4.8.2

> Port snapshot and upgrade mutex fixes to 4.8 branches
> -
>
> Key: PHOENIX-3436
> URL: https://issues.apache.org/jira/browse/PHOENIX-3436
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Fix For: 4.8.2
>
> Attachments: PHOENIX-3436.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[James Taylor]

Sounds good, except we've already moved on to 4.9 as we're voting on it
now. Second RC will be up today.

On Wednesday, November 2, 2016, Andrew Purtell  wrote:

> Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+ before
> moving on to 4.9 and up.
>
>
> On Wed, Nov 2, 2016 at 2:00 PM, > wrote:
>
> > Was going to do it this week. Then again, since 4.9.0 does not include
> the
> > column encoding I was less enthused about it.If we think we want a 4.8.2
> > I'll spin an RC today.
> > -- Lars
> >
> >   From: Andrew Purtell >
> >  To: "dev@phoenix.apache.org "  >
> > Cc: lars hofhansl >
> >  Sent: Wednesday, November 2, 2016 11:41 AM
> >  Subject: Re: 4.8.2 and/or 4.9.0
> >
> > Right, I think we should address PHOENIX-3407 in current 4.8.x releases
> > with a fixed version of it. I don't think we can ever fully understand
> the
> > version usage patterns of our users. I've seen folks write in to HBase
> > lists using 4 year old releases for unfathomable reasons.
> >
> > On Wed, Nov 2, 2016 at 11:38 AM, James Taylor  >
> > wrote:
> >
> > > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who
> would
> > > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0
> which
> > > has all the fixes in 4.8 branch (and more) and is compatible (as usual)
> > > with 4.8 releases through rolling restarts. At SFDC, we'll move to
> 4.9.0.
> > >
> > > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users
> > on
> > > HBase 1.2 should not use 4.8.0 or 4.8.1.
> > >
> > > Thanks,
> > > James
> > >
> > > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell  >
> > > wrote:
> > >
> > > > Need help with making a 4.8.2? I could try my hand at making a
> Phoenix
> > > > release.
> > > >
> > > >
> > > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor <
> jamestay...@apache.org >
> > > > wrote:
> > > >
> > > > > Current plan is to have a 4.9.0 RC in that same timeframe (by
> 10/31)
> > > with
> > > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> > PHOENIX-6
> > > > > (atomic insert/update).  If it's too much much for you to do both
> > 4.8.2
> > > > and
> > > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > > >
> > > > > On Sat, Oct 15, 2016 at 6:42 PM, >
> wrote:
> > > > >
> > > > > > Hi All,
> > > > > > we have 20 jiras against 4.8.2 some of which seem important
> enough
> > > ...
> > > > > and
> > > > > > over 200 against 4.9.0.
> > > > > > I think we should start keeping stable branches for longer.As
> > before
> > > > I'll
> > > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> > vastly
> > > > > > different opinions.
> > > > > >
> > > > > > -- Lars
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >- Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >   - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
> >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: 4.8.2 and/or 4.9.0

[Andrew Purtell]

Yes please I think we need a 4.8.x that fixes PHOENIX-3407 on 1.2+ before
moving on to 4.9 and up.


On Wed, Nov 2, 2016 at 2:00 PM,  wrote:

> Was going to do it this week. Then again, since 4.9.0 does not include the
> column encoding I was less enthused about it.If we think we want a 4.8.2
> I'll spin an RC today.
> -- Lars
>
>   From: Andrew Purtell 
>  To: "dev@phoenix.apache.org" 
> Cc: lars hofhansl 
>  Sent: Wednesday, November 2, 2016 11:41 AM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> Right, I think we should address PHOENIX-3407 in current 4.8.x releases
> with a fixed version of it. I don't think we can ever fully understand the
> version usage patterns of our users. I've seen folks write in to HBase
> lists using 4 year old releases for unfathomable reasons.
>
> On Wed, Nov 2, 2016 at 11:38 AM, James Taylor 
> wrote:
>
> > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who would
> > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0 which
> > has all the fixes in 4.8 branch (and more) and is compatible (as usual)
> > with 4.8 releases through rolling restarts. At SFDC, we'll move to 4.9.0.
> >
> > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users
> on
> > HBase 1.2 should not use 4.8.0 or 4.8.1.
> >
> > Thanks,
> > James
> >
> > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell 
> > wrote:
> >
> > > Need help with making a 4.8.2? I could try my hand at making a Phoenix
> > > release.
> > >
> > >
> > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
> > > wrote:
> > >
> > > > Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31)
> > with
> > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> PHOENIX-6
> > > > (atomic insert/update).  If it's too much much for you to do both
> 4.8.2
> > > and
> > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > >
> > > > On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
> > > >
> > > > > Hi All,
> > > > > we have 20 jiras against 4.8.2 some of which seem important enough
> > ...
> > > > and
> > > > > over 200 against 4.9.0.
> > > > > I think we should start keeping stable branches for longer.As
> before
> > > I'll
> > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> vastly
> > > > > different opinions.
> > > > >
> > > > > -- Lars
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>
>
>
> --
> Best regards,
>
>   - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
>
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

[jira] [Commented] (PHOENIX-3436) Port snapshot and upgrade mutex fixes to 4.8 branches

[Samarth Jain (JIRA)]

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

Samarth Jain commented on PHOENIX-3436:
---

Thanks, [~jamestaylor]. I will get the changes committed then.

> Port snapshot and upgrade mutex fixes to 4.8 branches
> -
>
> Key: PHOENIX-3436
> URL: https://issues.apache.org/jira/browse/PHOENIX-3436
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-3436.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3436) Port snapshot and upgrade mutex fixes to 4.8 branches

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3436:
---

Sounds good, [~samarthjain]. FWIW, typically cherry-picks of already reviewed 
fixes back to older branches don't need to be reviewed.

> Port snapshot and upgrade mutex fixes to 4.8 branches
> -
>
> Key: PHOENIX-3436
> URL: https://issues.apache.org/jira/browse/PHOENIX-3436
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-3436.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3436) Port snapshot and upgrade mutex fixes to 4.8 branches

[Samarth Jain (JIRA)]

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

Samarth Jain updated PHOENIX-3436:
--
Attachment: PHOENIX-3436.patch

Patch that I am going to commit unless there are objections.

> Port snapshot and upgrade mutex fixes to 4.8 branches
> -
>
> Key: PHOENIX-3436
> URL: https://issues.apache.org/jira/browse/PHOENIX-3436
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-3436.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3413) Ineffective null check in LiteralExpression#newConstant()

[Ted Yu (JIRA)]

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

Ted Yu updated PHOENIX-3413:

Description: 
{code}
if (maxLength == null) {
maxLength = type == null || !type.isFixedWidth() ? null : 
type.getMaxLength(value);
}
{code}

The null check for type is ineffective - type is de-referenced in various 
places prior to the above check.

  was:
{code}
if (maxLength == null) {
maxLength = type == null || !type.isFixedWidth() ? null : 
type.getMaxLength(value);
}
{code}
The null check for type is ineffective - type is de-referenced in various 
places prior to the above check.


> Ineffective null check in LiteralExpression#newConstant()
> -
>
> Key: PHOENIX-3413
> URL: https://issues.apache.org/jira/browse/PHOENIX-3413
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ted Yu
>Priority: Minor
>
> {code}
> if (maxLength == null) {
> maxLength = type == null || !type.isFixedWidth() ? null : 
> type.getMaxLength(value);
> }
> {code}
> The null check for type is ineffective - type is de-referenced in various 
> places prior to the above check.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[Samarth Jain]

Before cutting the RC, I would like to get
https://issues.apache.org/jira/browse/PHOENIX-3436 in. I didn't anticipate
that we will be doing more releases on the 4.8 branch. So didn't checkin
the fixes there. Will work on cherry picking the changes and commit them.

On Wed, Nov 2, 2016 at 2:00 PM,  wrote:

> Was going to do it this week. Then again, since 4.9.0 does not include the
> column encoding I was less enthused about it.If we think we want a 4.8.2
> I'll spin an RC today.
> -- Lars
>
>   From: Andrew Purtell 
>  To: "dev@phoenix.apache.org" 
> Cc: lars hofhansl 
>  Sent: Wednesday, November 2, 2016 11:41 AM
>  Subject: Re: 4.8.2 and/or 4.9.0
>
> Right, I think we should address PHOENIX-3407 in current 4.8.x releases
> with a fixed version of it. I don't think we can ever fully understand the
> version usage patterns of our users. I've seen folks write in to HBase
> lists using 4 year old releases for unfathomable reasons.
>
> On Wed, Nov 2, 2016 at 11:38 AM, James Taylor 
> wrote:
>
> > Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who would
> > not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0 which
> > has all the fixes in 4.8 branch (and more) and is compatible (as usual)
> > with 4.8 releases through rolling restarts. At SFDC, we'll move to 4.9.0.
> >
> > One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users
> on
> > HBase 1.2 should not use 4.8.0 or 4.8.1.
> >
> > Thanks,
> > James
> >
> > On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell 
> > wrote:
> >
> > > Need help with making a 4.8.2? I could try my hand at making a Phoenix
> > > release.
> > >
> > >
> > > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
> > > wrote:
> > >
> > > > Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31)
> > with
> > > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and
> PHOENIX-6
> > > > (atomic insert/update).  If it's too much much for you to do both
> 4.8.2
> > > and
> > > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > > >
> > > > On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
> > > >
> > > > > Hi All,
> > > > > we have 20 jiras against 4.8.2 some of which seem important enough
> > ...
> > > > and
> > > > > over 200 against 4.9.0.
> > > > > I think we should start keeping stable branches for longer.As
> before
> > > I'll
> > > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > > Let's think about a 4.8.2 in two weeks or so, unless there're
> vastly
> > > > > different opinions.
> > > > >
> > > > > -- Lars
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>
>
>
> --
> Best regards,
>
>   - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
>
>

[jira] [Created] (PHOENIX-3436) Port snapshot and upgrade mutex fixes to 4.8 branches

[Samarth Jain (JIRA)]

Samarth Jain created PHOENIX-3436:
-

 Summary: Port snapshot and upgrade mutex fixes to 4.8 branches
 Key: PHOENIX-3436
 URL: https://issues.apache.org/jira/browse/PHOENIX-3436
 Project: Phoenix
  Issue Type: Bug
Reporter: Samarth Jain
Assignee: Samarth Jain






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[larsh]

Was going to do it this week. Then again, since 4.9.0 does not include the 
column encoding I was less enthused about it.If we think we want a 4.8.2 I'll 
spin an RC today.
-- Lars

  From: Andrew Purtell 
 To: "dev@phoenix.apache.org"  
Cc: lars hofhansl 
 Sent: Wednesday, November 2, 2016 11:41 AM
 Subject: Re: 4.8.2 and/or 4.9.0
   
Right, I think we should address PHOENIX-3407 in current 4.8.x releases
with a fixed version of it. I don't think we can ever fully understand the
version usage patterns of our users. I've seen folks write in to HBase
lists using 4 year old releases for unfathomable reasons.

On Wed, Nov 2, 2016 at 11:38 AM, James Taylor 
wrote:

> Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who would
> not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0 which
> has all the fixes in 4.8 branch (and more) and is compatible (as usual)
> with 4.8 releases through rolling restarts. At SFDC, we'll move to 4.9.0.
>
> One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users on
> HBase 1.2 should not use 4.8.0 or 4.8.1.
>
> Thanks,
> James
>
> On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell 
> wrote:
>
> > Need help with making a 4.8.2? I could try my hand at making a Phoenix
> > release.
> >
> >
> > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
> > wrote:
> >
> > > Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31)
> with
> > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and PHOENIX-6
> > > (atomic insert/update).  If it's too much much for you to do both 4.8.2
> > and
> > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > >
> > > On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
> > >
> > > > Hi All,
> > > > we have 20 jiras against 4.8.2 some of which seem important enough
> ...
> > > and
> > > > over 200 against 4.9.0.
> > > > I think we should start keeping stable branches for longer.As before
> > I'll
> > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > Let's think about a 4.8.2 in two weeks or so, unless there're vastly
> > > > different opinions.
> > > >
> > > > -- Lars
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

  - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)


   

ready to cut 4.9.0 RC1

[James Taylor]

I believe we're ready to cut 4.9.0 RC1. If anything is missing that needs
to be in, please let us know right away.

Thanks,
James

[jira] [Resolved] (PHOENIX-3435) Upgrade will fail for future releases because of use of timestamp as value for upgrade mutex

[Samarth Jain (JIRA)]

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

Samarth Jain resolved PHOENIX-3435.
---
   Resolution: Fixed
Fix Version/s: 4.9.0

> Upgrade will fail for future releases because of use of timestamp as value 
> for upgrade mutex
> 
>
> Key: PHOENIX-3435
> URL: https://issues.apache.org/jira/browse/PHOENIX-3435
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3435.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3208:
--
Fix Version/s: 4.9.0

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
>Assignee: chenglei
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PHOENIX-3434) Avoid creating new Configuration in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

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

> Avoid creating new Configuration in ClientAggregatePlan to improve performance
> --
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch, PHOENIX-3434_addendum1.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3391) Supporting Hive 2.1.0 in PhoenixStorageHandler

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3391:
---

I agree, [~sergey.soldatov]. What we typically do with HBase is figure out a 
way to get it to work across both the old and new versions. Let's try that with 
this change as well.

> Supporting Hive 2.1.0 in PhoenixStorageHandler
> --
>
> Key: PHOENIX-3391
> URL: https://issues.apache.org/jira/browse/PHOENIX-3391
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>Priority: Minor
>  Labels: HivePhoenix
> Attachments: PHOENIX-3391.patch
>
>
> Hive with PhoenixStorageHandler throws TException when executing select 
> statement as following. the reason is that some hive public interface is 
> changed (ColumnProjectionUtils.getReadColumnNames()), so hive throws 
> NoSuchMethodError in PhoenixInputFormat class.
> org.apache.thrift.transport.TTransportException
>   at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.transport.TSaslTransport.readLength(TSaslTransport.java:376)
>   at 
> org.apache.thrift.transport.TSaslTransport.readFrame(TSaslTransport.java:453)
>   at 
> org.apache.thrift.transport.TSaslTransport.read(TSaslTransport.java:435)
>   at 
> org.apache.thrift.transport.TSaslClientTransport.read(TSaslClientTransport.java:37)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:77)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.recv_FetchResults(TCLIService.java:559)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.FetchResults(TCLIService.java:546)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.hive.jdbc.HiveConnection$SynchronizedHandler.invoke(HiveConnection.java:1426)
>   at com.sun.proxy.$Proxy16.FetchResults(Unknown Source)
>   at 
> org.apache.hive.jdbc.HiveQueryResultSet.next(HiveQueryResultSet.java:372)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3391) Supporting Hive 2.1.0 in PhoenixStorageHandler

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-3391:
--

[~Jeongdae Kim] Thank you for the patch! Apache Hive 2.1 was recently released 
and most of the user are still using older versions. I think we have to 
postpone this fix and add note to the Apache Phoenix documentation that if 
someone want to get it working with Apache Hive 2.1, they need to recompile 
Apache Phoenix with this fix.

> Supporting Hive 2.1.0 in PhoenixStorageHandler
> --
>
> Key: PHOENIX-3391
> URL: https://issues.apache.org/jira/browse/PHOENIX-3391
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>Priority: Minor
>  Labels: HivePhoenix
> Attachments: PHOENIX-3391.patch
>
>
> Hive with PhoenixStorageHandler throws TException when executing select 
> statement as following. the reason is that some hive public interface is 
> changed (ColumnProjectionUtils.getReadColumnNames()), so hive throws 
> NoSuchMethodError in PhoenixInputFormat class.
> org.apache.thrift.transport.TTransportException
>   at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.transport.TSaslTransport.readLength(TSaslTransport.java:376)
>   at 
> org.apache.thrift.transport.TSaslTransport.readFrame(TSaslTransport.java:453)
>   at 
> org.apache.thrift.transport.TSaslTransport.read(TSaslTransport.java:435)
>   at 
> org.apache.thrift.transport.TSaslClientTransport.read(TSaslClientTransport.java:37)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:77)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.recv_FetchResults(TCLIService.java:559)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.FetchResults(TCLIService.java:546)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.hive.jdbc.HiveConnection$SynchronizedHandler.invoke(HiveConnection.java:1426)
>   at com.sun.proxy.$Proxy16.FetchResults(Unknown Source)
>   at 
> org.apache.hive.jdbc.HiveQueryResultSet.next(HiveQueryResultSet.java:372)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3435) Upgrade will fail for future releases because of use of timestamp as value for upgrade mutex

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3435:
---

+1

> Upgrade will fail for future releases because of use of timestamp as value 
> for upgrade mutex
> 
>
> Key: PHOENIX-3435
> URL: https://issues.apache.org/jira/browse/PHOENIX-3435
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-3435.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3434) Avoid creating new Configuration in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3434:
--
Attachment: PHOENIX-3434_addendum1.patch

> Avoid creating new Configuration in ClientAggregatePlan to improve performance
> --
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch, PHOENIX-3434_addendum1.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3434) Avoid creating new Configuration in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3434:
--
Summary: Avoid creating new Configuration in ClientAggregatePlan to improve 
performance  (was: Avoid deserialization of ServerAggregators in 
ClientAggregatePlan to improve performance)

> Avoid creating new Configuration in ClientAggregatePlan to improve performance
> --
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch, PHOENIX-3434_addendum1.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3408) arithmetic/mathematical operations with Decimal columns failed in Hive with PheonixStorageHandler.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3408:
-
Fix Version/s: 4.9.0

> arithmetic/mathematical operations with Decimal columns failed in Hive with 
> PheonixStorageHandler.
> --
>
> Key: PHOENIX-3408
> URL: https://issues.apache.org/jira/browse/PHOENIX-3408
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3408.patch
>
>
> PhoenixDecimalObjectInspector doesn't hold decimal type information (holds 
> default max precision/scale (38/10)), so it doesn't make correct object that 
> fits into the schema. this causes incorrect results for decimal operations 
> (+, -, *, -, functions...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3386) PhoenixStorageHandler throws NPE if local tasks executed via child

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3386:
-
Fix Version/s: 4.9.0

> PhoenixStorageHandler throws NPE if local tasks executed via child
> --
>
> Key: PHOENIX-3386
> URL: https://issues.apache.org/jira/browse/PHOENIX-3386
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3386.patch
>
>
> By default hive is using hive.exec.submit.local.task.via.child as true. In 
> this case all MR tasks are running in separate processes and in this case NPE 
> is thrown from PhoenixStorageHandler.getTableKeyOfSession. The reason is that 
> in new process the SessionState returns null and method is unable to build 
> key for session. We need to pass session id through jobConf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3423) PhoenixObjectInspector doesn't have information on length of the column.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3423:
-
Fix Version/s: 4.9.0

> PhoenixObjectInspector doesn't have information on length of the column.
> 
>
> Key: PHOENIX-3423
> URL: https://issues.apache.org/jira/browse/PHOENIX-3423
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3423.patch
>
>
> PhoenixObjectInspector doesn't have information on length of the column. this 
> causes making incorrect constant valuesfor char columns in select statement 
> because of padding spaces with max length(255), and get wrong results because 
> of invalid filter conditions.
> ex) column : r_name char(6), 
> hive query : select * from r_name = 'EUROPE',
> phoenix query : select * from r_name = 'EUROPE' (with 
> 249(255 - 6) tailing white spaces)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3423) PhoenixObjectInspector doesn't have information on length of the column.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-3423:
--

+1 
Committed to master and 4.x branches. Thank you, [~Jeongdae Kim] !

> PhoenixObjectInspector doesn't have information on length of the column.
> 
>
> Key: PHOENIX-3423
> URL: https://issues.apache.org/jira/browse/PHOENIX-3423
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3423.patch
>
>
> PhoenixObjectInspector doesn't have information on length of the column. this 
> causes making incorrect constant valuesfor char columns in select statement 
> because of padding spaces with max length(255), and get wrong results because 
> of invalid filter conditions.
> ex) column : r_name char(6), 
> hive query : select * from r_name = 'EUROPE',
> phoenix query : select * from r_name = 'EUROPE' (with 
> 249(255 - 6) tailing white spaces)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3387) Hive PhoenixStorageHandler fails with join on numeric fields

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3387:
-
Fix Version/s: 4.9.0

> Hive PhoenixStorageHandler fails with join on numeric fields
> 
>
> Key: PHOENIX-3387
> URL: https://issues.apache.org/jira/browse/PHOENIX-3387
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3387.patch
>
>
> If condition for join is using numeric field, the MR job fails with class 
> cast exception. The reason is that all object inspectors for numeric types 
> doesn't implement getPrimitiveWritableObject method. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3416) Memory leak in PhoenixStorageHandler

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3416:
-
Fix Version/s: 4.9.0

> Memory leak in PhoenixStorageHandler
> 
>
> Key: PHOENIX-3416
> URL: https://issues.apache.org/jira/browse/PHOENIX-3416
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3416.patch
>
>
> when executing EXPLAIN query, hive doesn't execute Tasks that get and remove 
> PhoenixPredicateDecomposer from PREDICATE_DECOMPOSER_MAP. so, all predicate 
> decomposers made from the explain query exists forever in the decomposer map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3422) PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) column type.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov updated PHOENIX-3422:
-
Fix Version/s: 4.9.0

> PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) 
> column type.
> ---
>
> Key: PHOENIX-3422
> URL: https://issues.apache.org/jira/browse/PHOENIX-3422
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3422.patch
>
>
> with a query that includes (v)char column type expression in where clause , a 
> query builder can't make a value string that is wrapped with single quote 
> character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3408) arithmetic/mathematical operations with Decimal columns failed in Hive with PheonixStorageHandler.

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-3408:
--

LGTM. Committed to master and 4.x branches. Thank you, [~Jeongdae Kim] !

> arithmetic/mathematical operations with Decimal columns failed in Hive with 
> PheonixStorageHandler.
> --
>
> Key: PHOENIX-3408
> URL: https://issues.apache.org/jira/browse/PHOENIX-3408
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3408.patch
>
>
> PhoenixDecimalObjectInspector doesn't hold decimal type information (holds 
> default max precision/scale (38/10)), so it doesn't make correct object that 
> fits into the schema. this causes incorrect results for decimal operations 
> (+, -, *, -, functions...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3387) Hive PhoenixStorageHandler fails with join on numeric fields

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-3387:
--

committed to master & 4.x branches

> Hive PhoenixStorageHandler fails with join on numeric fields
> 
>
> Key: PHOENIX-3387
> URL: https://issues.apache.org/jira/browse/PHOENIX-3387
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Attachments: PHOENIX-3387.patch
>
>
> If condition for join is using numeric field, the MR job fails with class 
> cast exception. The reason is that all object inspectors for numeric types 
> doesn't implement getPrimitiveWritableObject method. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3254) IndexId Sequence is incremented even if index exists already.

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3254:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1468 (See 
[https://builds.apache.org/job/Phoenix-master/1468/])
PHOENIX-3433 Local or view indexes cannot be created after PHOENIX-3254 
(rajeshbabu: rev 8a44cc00101e44e0afd2cadb2b5a4a1eba6052fe)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/BaseLocalIndexIT.java


> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3433) Local or view indexes cannot be created after PHOENIX-3254 if namespaces enabled

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-3433:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1468 (See 
[https://builds.apache.org/job/Phoenix-master/1468/])
PHOENIX-3433 Local or view indexes cannot be created after PHOENIX-3254 
(rajeshbabu: rev 8a44cc00101e44e0afd2cadb2b5a4a1eba6052fe)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/BaseLocalIndexIT.java


> Local or view indexes cannot be created after PHOENIX-3254 if namespaces 
> enabled
> 
>
> Key: PHOENIX-3433
> URL: https://issues.apache.org/jira/browse/PHOENIX-3433
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Blocker
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3433.patch
>
>
> As part of PHOENIX-3254 we are trying to create sequences at server while 
> creating local or view indexes. When we try to create a connection we are 
> always going by namespace config false. So by the time if the SYSTEM tables 
> created with namespaces then we get error while creating local or view 
> indexes. If we need to set the namespace enabled or not as for server 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3434) Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3434:
---

Actually, I think I've figured out why, [~maryannxue]. Addendum patch soon.

> Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve 
> performance
> 
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3434) Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3434:
---

[~maryannxue]. Looks like my patch breaks SubqueryIT:
{code}
Failed tests: 
  SubqueryIT.testAnyAllComparisonSubquery:701
  SubqueryIT.testAnyAllComparisonSubquery:701
  SubqueryIT.testAnyAllComparisonSubquery:701

Tests run: 21, Failures: 3, Errors: 0, Skipped: 0
{code}

Any idea why?

> Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve 
> performance
> 
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3435) Upgrade will fail for future releases because of use of timestamp as value for upgrade mutex

[Samarth Jain (JIRA)]

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

Samarth Jain updated PHOENIX-3435:
--
Attachment: PHOENIX-3435.patch

[~jamestaylor], please review. 

Hopefully this is the last patch to address issues around upgrade related 
changes that have been made.

> Upgrade will fail for future releases because of use of timestamp as value 
> for upgrade mutex
> 
>
> Key: PHOENIX-3435
> URL: https://issues.apache.org/jira/browse/PHOENIX-3435
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-3435.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3435) Upgrade will fail for future releases because of use of timestamp as value for upgrade mutex

[Samarth Jain (JIRA)]

Samarth Jain created PHOENIX-3435:
-

 Summary: Upgrade will fail for future releases because of use of 
timestamp as value for upgrade mutex
 Key: PHOENIX-3435
 URL: https://issues.apache.org/jira/browse/PHOENIX-3435
 Project: Phoenix
  Issue Type: Bug
Reporter: Samarth Jain
Assignee: Samarth Jain






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[Andrew Purtell]

Right, I think we should address PHOENIX-3407 in current 4.8.x releases
with a fixed version of it. I don't think we can ever fully understand the
version usage patterns of our users. I've seen folks write in to HBase
lists using 4 year old releases for unfathomable reasons.

On Wed, Nov 2, 2016 at 11:38 AM, James Taylor 
wrote:

> Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who would
> not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0 which
> has all the fixes in 4.8 branch (and more) and is compatible (as usual)
> with 4.8 releases through rolling restarts. At SFDC, we'll move to 4.9.0.
>
> One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users on
> HBase 1.2 should not use 4.8.0 or 4.8.1.
>
> Thanks,
> James
>
> On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell 
> wrote:
>
> > Need help with making a 4.8.2? I could try my hand at making a Phoenix
> > release.
> >
> >
> > On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
> > wrote:
> >
> > > Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31)
> with
> > > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and PHOENIX-6
> > > (atomic insert/update).  If it's too much much for you to do both 4.8.2
> > and
> > > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> > >
> > > On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
> > >
> > > > Hi All,
> > > > we have 20 jiras against 4.8.2 some of which seem important enough
> ...
> > > and
> > > > over 200 against 4.9.0.
> > > > I think we should start keeping stable branches for longer.As before
> > I'll
> > > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > > Let's think about a 4.8.2 in two weeks or so, unless there're vastly
> > > > different opinions.
> > > >
> > > > -- Lars
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 4.8.2 and/or 4.9.0

[James Taylor]

Thanks, Andrew. One question: are there users on 4.8.0 or 4.8.1 who would
not want to upgrade to 4.9.0? We're in the voting stage for a 4.9.0 which
has all the fixes in 4.8 branch (and more) and is compatible (as usual)
with 4.8 releases through rolling restarts. At SFDC, we'll move to 4.9.0.

One thing is clear, though. Given PHOENIX-3407 (and HBASE-14465), users on
HBase 1.2 should not use 4.8.0 or 4.8.1.

Thanks,
James

On Wed, Nov 2, 2016 at 11:07 AM, Andrew Purtell  wrote:

> Need help with making a 4.8.2? I could try my hand at making a Phoenix
> release.
>
>
> On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
> wrote:
>
> > Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31) with
> > the column encoding work (PHOENIX-1598 and PHOENIX-2565) and PHOENIX-6
> > (atomic insert/update).  If it's too much much for you to do both 4.8.2
> and
> > 4.9 simultaneously, I can volunteer to be the RM for 4.9.
> >
> > On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
> >
> > > Hi All,
> > > we have 20 jiras against 4.8.2 some of which seem important enough ...
> > and
> > > over 200 against 4.9.0.
> > > I think we should start keeping stable branches for longer.As before
> I'll
> > > volunteer doing 4.8.2 as well as a 4.9.0.
> > > Let's think about a 4.8.2 in two weeks or so, unless there're vastly
> > > different opinions.
> > >
> > > -- Lars
> > >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

[jira] [Updated] (PHOENIX-3423) PhoenixObjectInspector doesn't have information on length of the column.

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3423:
--
Assignee: Jeongdae Kim

> PhoenixObjectInspector doesn't have information on length of the column.
> 
>
> Key: PHOENIX-3423
> URL: https://issues.apache.org/jira/browse/PHOENIX-3423
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
> Attachments: PHOENIX-3423.patch
>
>
> PhoenixObjectInspector doesn't have information on length of the column. this 
> causes making incorrect constant valuesfor char columns in select statement 
> because of padding spaces with max length(255), and get wrong results because 
> of invalid filter conditions.
> ex) column : r_name char(6), 
> hive query : select * from r_name = 'EUROPE',
> phoenix query : select * from r_name = 'EUROPE' (with 
> 249(255 - 6) tailing white spaces)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3408) arithmetic/mathematical operations with Decimal columns failed in Hive with PheonixStorageHandler.

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3408:
--
Assignee: Jeongdae Kim

> arithmetic/mathematical operations with Decimal columns failed in Hive with 
> PheonixStorageHandler.
> --
>
> Key: PHOENIX-3408
> URL: https://issues.apache.org/jira/browse/PHOENIX-3408
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3408.patch
>
>
> PhoenixDecimalObjectInspector doesn't hold decimal type information (holds 
> default max precision/scale (38/10)), so it doesn't make correct object that 
> fits into the schema. this causes incorrect results for decimal operations 
> (+, -, *, -, functions...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3386) PhoenixStorageHandler throws NPE if local tasks executed via child

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3386:
---

+1

> PhoenixStorageHandler throws NPE if local tasks executed via child
> --
>
> Key: PHOENIX-3386
> URL: https://issues.apache.org/jira/browse/PHOENIX-3386
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>  Labels: HivePhoenix
> Attachments: PHOENIX-3386.patch
>
>
> By default hive is using hive.exec.submit.local.task.via.child as true. In 
> this case all MR tasks are running in separate processes and in this case NPE 
> is thrown from PhoenixStorageHandler.getTableKeyOfSession. The reason is that 
> in new process the SessionState returns null and method is unable to build 
> key for session. We need to pass session id through jobConf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 4.8.2 and/or 4.9.0

[Andrew Purtell]

Need help with making a 4.8.2? I could try my hand at making a Phoenix
release.


On Sat, Oct 15, 2016 at 7:06 PM, James Taylor 
wrote:

> Current plan is to have a 4.9.0 RC in that same timeframe (by 10/31) with
> the column encoding work (PHOENIX-1598 and PHOENIX-2565) and PHOENIX-6
> (atomic insert/update).  If it's too much much for you to do both 4.8.2 and
> 4.9 simultaneously, I can volunteer to be the RM for 4.9.
>
> On Sat, Oct 15, 2016 at 6:42 PM,  wrote:
>
> > Hi All,
> > we have 20 jiras against 4.8.2 some of which seem important enough ...
> and
> > over 200 against 4.9.0.
> > I think we should start keeping stable branches for longer.As before I'll
> > volunteer doing 4.8.2 as well as a 4.9.0.
> > Let's think about a 4.8.2 in two weeks or so, unless there're vastly
> > different opinions.
> >
> > -- Lars
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

[jira] [Updated] (PHOENIX-3391) Supporting Hive 2.1.0 in PhoenixStorageHandler

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3391:
--
Assignee: Jeongdae Kim

> Supporting Hive 2.1.0 in PhoenixStorageHandler
> --
>
> Key: PHOENIX-3391
> URL: https://issues.apache.org/jira/browse/PHOENIX-3391
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>Priority: Minor
>  Labels: HivePhoenix
> Attachments: PHOENIX-3391.patch
>
>
> Hive with PhoenixStorageHandler throws TException when executing select 
> statement as following. the reason is that some hive public interface is 
> changed (ColumnProjectionUtils.getReadColumnNames()), so hive throws 
> NoSuchMethodError in PhoenixInputFormat class.
> org.apache.thrift.transport.TTransportException
>   at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.transport.TSaslTransport.readLength(TSaslTransport.java:376)
>   at 
> org.apache.thrift.transport.TSaslTransport.readFrame(TSaslTransport.java:453)
>   at 
> org.apache.thrift.transport.TSaslTransport.read(TSaslTransport.java:435)
>   at 
> org.apache.thrift.transport.TSaslClientTransport.read(TSaslClientTransport.java:37)
>   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318)
>   at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>   at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:77)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.recv_FetchResults(TCLIService.java:559)
>   at 
> org.apache.hive.service.rpc.thrift.TCLIService$Client.FetchResults(TCLIService.java:546)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.hive.jdbc.HiveConnection$SynchronizedHandler.invoke(HiveConnection.java:1426)
>   at com.sun.proxy.$Proxy16.FetchResults(Unknown Source)
>   at 
> org.apache.hive.jdbc.HiveQueryResultSet.next(HiveQueryResultSet.java:372)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3422) PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) column type.

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3422:
---

This one too, please [~sergey.soldatov].

> PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) 
> column type.
> ---
>
> Key: PHOENIX-3422
> URL: https://issues.apache.org/jira/browse/PHOENIX-3422
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3422.patch
>
>
> with a query that includes (v)char column type expression in where clause , a 
> query builder can't make a value string that is wrapped with single quote 
> character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3422) PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) column type.

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3422:
--
Assignee: Jeongdae Kim

> PhoenixQueryBuilder doesn't make value string correctly for char(/varchar) 
> column type.
> ---
>
> Key: PHOENIX-3422
> URL: https://issues.apache.org/jira/browse/PHOENIX-3422
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3422.patch
>
>
> with a query that includes (v)char column type expression in where clause , a 
> query builder can't make a value string that is wrapped with single quote 
> character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3416) Memory leak in PhoenixStorageHandler

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3416:
--
Assignee: Jeongdae Kim

> Memory leak in PhoenixStorageHandler
> 
>
> Key: PHOENIX-3416
> URL: https://issues.apache.org/jira/browse/PHOENIX-3416
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>Assignee: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3416.patch
>
>
> when executing EXPLAIN query, hive doesn't execute Tasks that get and remove 
> PhoenixPredicateDecomposer from PREDICATE_DECOMPOSER_MAP. so, all predicate 
> decomposers made from the explain query exists forever in the decomposer map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[CANCEL][VOTE] Release of Apache Phoenix 4.9.0 RC0

[James Taylor]

Several showstoppers came up: PHOENIX-3433 and PHOENIX-3432 among them.
We'll cut a new RC today.

Thanks,
James

On Wed, Nov 2, 2016 at 2:38 AM, rajeshb...@apache.org <
chrajeshbab...@gmail.com> wrote:

> James,
>
> Found PHOENIX-3433. It's a blocker. I think we need to make other RC.
>
> Thanks,
> Rajeshbabu.
>
> On Wed, Nov 2, 2016 at 8:08 AM, 김영우 (YoungWoo Kim) 
> wrote:
>
> > Hi James,
> >
> > I have a problem while upgrading 4.8.0 to 4.9.0 rc0. Filed PHOENIX-3432.
> >
> > Thanks,
> > Youngwoo
> >
> > 2016. 11. 1. 오전 9:22에 "James Taylor" 님이 작성:
> >
> > > Hello Everyone,
> > >
> > > This is a call for a vote on Apache Phoenix 4.9.0 RC0. This is the next
> > > minor release of Phoenix 4, compatible with Apache HBase 0.98, 1.1 &
> 1.2.
> > > The release includes both a source-only release and a convenience
> binary
> > > release for each supported HBase version.
> > >
> > > This release has feature parity with supported HBase versions and
> > includes
> > > the following improvements:
> > > - Atomic upsert through new ON DUPLICATE KEY syntax [1]
> > > - Support for DEFAULT declaration in DDL statements [2]
> > > - Specify guidepost width per table [3]
> > > - 38 bugs resolved
> > >
> > > The source tarball, including signatures, digests, etc can be found at:
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-0.98-rc0/src/
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-1.1-rc0/src/
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-1.2-rc0/src/
> > >
> > > The binary artifacts can be found at:
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-0.98-rc0/bin/
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-1.1-rc0/bin/
> > > https://dist.apache.org/repos/dist/dev/phoenix/apache-
> > > phoenix-4.9.0-HBase-1.2-rc0/bin/
> > >
> > > For a complete list of changes, see:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > projectId=12315120=12335845
> > >
> > > 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=
> > > d45feaedbe3611cbc38e8a053f5560f391bcd2b8
> > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
> > > h=refs/tags/v4.9.0-HBase-0.98-rc0
> > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=
> > > f668b010b40ff8a8f5f1d53c16bd64bd0d5a8a08
> > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
> > > h=refs/tags/v4.9.0-HBase-1.1-rc0
> > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=
> > > effb095230f9f0a3e9b00e1925c6ed797ff5666c
> > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;
> > > h=refs/tags/v4.9.0-HBase-1.2-rc0
> > >
> > > Vote will be open for 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-6
> > > [2] https://issues.apache.org/jira/browse/PHOENIX-476
> > > [3] https://issues.apache.org/jira/browse/PHOENIX-2675
> > >
> >
>

[jira] [Commented] (PHOENIX-3434) Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve performance

[Maryann Xue (JIRA)]

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

Maryann Xue commented on PHOENIX-3434:
--

+1. Thank you, [~jamestaylor], for fixing this!

> Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve 
> performance
> 
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3434) Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3434:
--
Attachment: PHOENIX-3434.patch

Please review, [~maryannxue]. FYI, we'd like to get this into the next 4.9.0 RC 
later today.

FYI, [~jpalmert].

> Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve 
> performance
> 
>
> Key: PHOENIX-3434
> URL: https://issues.apache.org/jira/browse/PHOENIX-3434
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3434.patch
>
>
> The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow 
> and can be avoided by constructing the ServerAggregators from the 
> ClientAggregators instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3434) Avoid deserialization of ServerAggregators in ClientAggregatePlan to improve performance

[James Taylor (JIRA)]

James Taylor created PHOENIX-3434:
-

 Summary: Avoid deserialization of ServerAggregators in 
ClientAggregatePlan to improve performance
 Key: PHOENIX-3434
 URL: https://issues.apache.org/jira/browse/PHOENIX-3434
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor
Assignee: James Taylor
 Fix For: 4.9.0


The call to HBaseConfiguration.create() in ClientAggregatePlan is very slow and 
can be avoided by constructing the ServerAggregators from the ClientAggregators 
instead (since this all occurs on the client side).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in snapshot name

[Samarth Jain (JIRA)]

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

Samarth Jain updated PHOENIX-3432:
--
Summary: Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters 
in snapshot name  (was: Upgrade Phoenix 4.8.0 to 4.9.0 failed)

> Upgrade Phoenix 4.8.0 to 4.9.0 fails because of illegal characters in 
> snapshot name
> ---
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table 

[jira] [Commented] (PHOENIX-3427) rdd.saveToPhoenix gives table undefined error when attempting to write to a tenant-specific view (TenantId defined in configuration object and passed to saveToPhoenix

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3427:
---

Wow, congrats on the baby, [~jmahonin]. We want to see a pic now!

You've been extremely responsive, so we really appreciate that. I'll spend some 
time with [~nico.pappagianis] today and we'll see if we can get to the bottom 
of it.

> rdd.saveToPhoenix gives table undefined error when attempting to write to a 
> tenant-specific view (TenantId defined in configuration object and passed to 
> saveToPhoenix)
> ---
>
> Key: PHOENIX-3427
> URL: https://issues.apache.org/jira/browse/PHOENIX-3427
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Nico Pappagianis
>
> Although we can read from a tenant-specific view by passing TenantId in the 
> conf object when calling sc.phoenixTableAsRDD the same does not hold for 
> rdd.saveToPhoenix. Calling saveToPhoenix with a tenant-specific view as the 
> table name gives a table undefined error, even when passing in the TenantId 
> with the conf object.
> It appears that TenantId is lost during the execution path of saveToPhoenix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3427) rdd.saveToPhoenix gives table undefined error when attempting to write to a tenant-specific view (TenantId defined in configuration object and passed to saveToPhoenix

[Josh Mahonin (JIRA)]

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

Josh Mahonin commented on PHOENIX-3427:
---

Hi [~nico.pappagianis]

Thanks for the info. As I recall, the conf isn't passed through tot he 
'partitionConfig' due to the fact that the Configuration object isn't 
serializable. Everything that executes in the 'mapPartitions()' call is running 
on a worker, but the 'outConfig' lives on the driver.

As a first try, you could attempt to retrieve the 'TenantID' parameter from the 
'outConfig' ([1| 
https://github.com/apache/phoenix/blob/master/phoenix-spark/src/main/scala/org/apache/phoenix/spark/ProductRDDFunctions.scala#L32])
 to a local variable. Then you could set that parameter again on the 
'partitionConfig' 
([2|https://github.com/apache/phoenix/blob/master/phoenix-spark/src/main/scala/org/apache/phoenix/spark/ProductRDDFunctions.scala#L40])

It's not very elegant, unfortunately the Phoenix connection settings weren't 
really considered with this code. The DataFrame API also has a notion of 
options that we could leverage to support the connection properties as well. 
Patches are most welcome. :)

(On a personal note, sorry for being a bit negligent on responding to the Spark 
stuff, $DAYJOB is nuts and my wife and I just had a baby)


> rdd.saveToPhoenix gives table undefined error when attempting to write to a 
> tenant-specific view (TenantId defined in configuration object and passed to 
> saveToPhoenix)
> ---
>
> Key: PHOENIX-3427
> URL: https://issues.apache.org/jira/browse/PHOENIX-3427
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Nico Pappagianis
>
> Although we can read from a tenant-specific view by passing TenantId in the 
> conf object when calling sc.phoenixTableAsRDD the same does not hold for 
> rdd.saveToPhoenix. Calling saveToPhoenix with a tenant-specific view as the 
> table name gives a table undefined error, even when passing in the TenantId 
> with the conf object.
> It appears that TenantId is lost during the execution path of saveToPhoenix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3432:
---

+1. Thanks, [~samarthjain].

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> 

[jira] [Updated] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3432:
--
Fix Version/s: 4.9.0

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to find the 
> table 

[jira] [Updated] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3432:
--
Assignee: Samarth Jain

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to find the 
> table 

[jira] [Updated] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3432:
--
Fix Version/s: 4.8.2

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
>Assignee: Samarth Jain
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to find the 
> table 

[jira] [Updated] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[Samarth Jain (JIRA)]

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

Samarth Jain updated PHOENIX-3432:
--
Attachment: PHOENIX-3432_v2.patch

Patch updated with review comments.

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
> Attachments: PHOENIX-3432.patch, PHOENIX-3432_v2.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> snapshot=SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: 
> org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to find the 
> table name for 
> 

[jira] [Commented] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3208:
---

+1. Nice find, [~comnetwork]. We'll get this in the next 4.9.0 RC.

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
>Assignee: chenglei
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3208:
--
Assignee: chenglei

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
>Assignee: chenglei
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3432) Upgrade Phoenix 4.8.0 to 4.9.0 failed

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3432:
---

How about formatting the date/time without the +timezone part as it's somewhat 
known that times in Phoenix are GMT? I think this is slightly better than using 
System.currentTimeMillis() since the user can gleam more easily *when* the 
snapshot was made.

> Upgrade Phoenix 4.8.0 to 4.9.0 failed
> -
>
> Key: PHOENIX-3432
> URL: https://issues.apache.org/jira/browse/PHOENIX-3432
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
> Environment: HBase 1.1.7, Phoenix 4.9.0 RC0
>Reporter: YoungWoo Kim
> Attachments: PHOENIX-3432.patch
>
>
> Trying to upgrade 4.8.0 to 4.9.0, I did stop the all hbase services and 
> upgraded Phoenix binary to 4.9.0 RC0 and then, restarted hbase services. 
> actually I'm trying automatic upgrade using sqlline but it does not works as 
> I expected.
> {noformat}
> 16/11/02 09:53:03 WARN query.ConnectionQueryServicesImpl: Successfully 
> enabled SYSTEM:CATALOG after restoring using snapshot 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 failed. 
> Error: java.lang.IllegalArgumentException: Illegal character code:58, <:> at 
> 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900 
> (state=,code=0)
> java.sql.SQLException: java.lang.IllegalArgumentException: Illegal character 
> code:58, <:> at 15. Snapshot qualifiers can only contain 'alphanumeric 
> characters': i.e. [a-zA-Z_0-9-.]: 
> SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2843)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.upgradeSystemTables(ConnectionQueryServicesImpl.java:2524)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2427)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl$13.call(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:76)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:2361)
>   at 
> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:232)
>   at 
> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:147)
>   at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:202)
>   at sqlline.DatabaseConnection.connect(DatabaseConnection.java:157)
>   at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:203)
>   at sqlline.Commands.connect(Commands.java:1064)
>   at sqlline.Commands.connect(Commands.java:996)
>   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 
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
>   at sqlline.SqlLine.dispatch(SqlLine.java:809)
>   at sqlline.SqlLine.initArgs(SqlLine.java:588)
>   at sqlline.SqlLine.begin(SqlLine.java:661)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.IllegalArgumentException: Illegal character code:58, <:> 
> at 15. Snapshot qualifiers can only contain 'alphanumeric characters': i.e. 
> [a-zA-Z_0-9-.]: SNAPSHOT_SYSTEM:CATALOG_4.8.x_TO_4.9.0_20161102095256+0900
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:196)
>   at 
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:154)
>   at 
> org.apache.hadoop.hbase.snapshot.ClientSnapshotDescriptionUtils.assertSnapshotRequestIsValid(ClientSnapshotDescriptionUtils.java:42)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.takeSnapshotAsync(HBaseAdmin.java:3568)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3516)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3474)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:3393)
>   at 
> org.apache.phoenix.query.ConnectionQueryServicesImpl.createSnapshot(ConnectionQueryServicesImpl.java:2839)
>   ... 22 more
> Error: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Unable to 
> find the table name for 
> 

[jira] [Commented] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3208:


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

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

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{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 
43 warning messages.

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

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+return PhoenixRuntime.JDBC_PROTOCOL + 
PhoenixRuntime.JDBC_PROTOCOL_SEPARATOR + PhoenixRuntime.CONNECTIONLESS;
+conn.createStatement().execute("upsert into 
MUTATION_TEST1(id1,appId1) values(111,'app1')");
+conn.createStatement().execute("upsert into 
MUTATION_TEST2(id2,appId2) values(222,'app2')");
+private void assertTable(String tableName1,List 
keyValues1,String tableName2,List keyValues2) {
+
assertTrue(Bytes.equals(PUnsignedInt.INSTANCE.toBytes(111),CellUtil.cloneRow(keyValues1.get(0;
+
assertTrue("app1".equals(PVarchar.INSTANCE.toObject(CellUtil.cloneValue(keyValues1.get(0);
+
assertTrue(Bytes.equals(PUnsignedInt.INSTANCE.toBytes(222),CellUtil.cloneRow(keyValues2.get(0;
+
assertTrue("app2".equals(PVarchar.INSTANCE.toObject(CellUtil.cloneValue(keyValues2.get(0);

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

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

This message is automatically generated.

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> 

[jira] [Updated] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[chenglei (JIRA)]

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

chenglei updated PHOENIX-3208:
--
Attachment: PHOENIX-3208_v5.patch

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[chenglei (JIRA)]

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

chenglei updated PHOENIX-3208:
--
Attachment: (was: PHOENIX-3208_v4.patch)

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
> Attachments: PHOENIX-3208_v5.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST1(id1,appId1) values(111,'app1')");
> conn.createStatement().execute("upsert into 
> MUTATION_TEST2(id2,appId2) values(222,'app2')");
> Iterator> 
> dataTableNameAndMutationKeyValuesIter =
> PhoenixRuntime.getUncommittedDataIterator(conn);
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> Pair 
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName1=Bytes.toString(pair.getFirst());
> List keyValues1=pair.getSecond();
> assertTrue(dataTableNameAndMutationKeyValuesIter.hasNext());
> pair=dataTableNameAndMutationKeyValuesIter.next();
> String tableName2=Bytes.toString(pair.getFirst());
> List keyValues2=pair.getSecond();
> if("MUTATION_TEST1".equals(tableName1)) {
> assertTable(tableName1, keyValues1, tableName2, keyValues2);
> }
> else {
> assertTable(tableName2, keyValues2, tableName1, keyValues1);
> }
> assertTrue(!dataTableNameAndMutationKeyValuesIter.hasNext());
> }
> finally {
> if(conn!=null) {
> conn.close();
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3416) Memory leak in PhoenixStorageHandler

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3416:
---

Thanks, [~sergey.soldatov]. If you're able to review and commit them today, yes 
I think it'd be good to get them in the RC.

> Memory leak in PhoenixStorageHandler
> 
>
> Key: PHOENIX-3416
> URL: https://issues.apache.org/jira/browse/PHOENIX-3416
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Jeongdae Kim
>  Labels: HivePhoenix
> Attachments: PHOENIX-3416.patch
>
>
> when executing EXPLAIN query, hive doesn't execute Tasks that get and remove 
> PhoenixPredicateDecomposer from PREDICATE_DECOMPOSER_MAP. so, all predicate 
> decomposers made from the explain query exists forever in the decomposer map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3433) Local or view indexes cannot be created after PHOENIX-3254 if namespaces enabled

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-3433:
---

+1

> Local or view indexes cannot be created after PHOENIX-3254 if namespaces 
> enabled
> 
>
> Key: PHOENIX-3433
> URL: https://issues.apache.org/jira/browse/PHOENIX-3433
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Blocker
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3433.patch
>
>
> As part of PHOENIX-3254 we are trying to create sequences at server while 
> creating local or view indexes. When we try to create a connection we are 
> always going by namespace config false. So by the time if the SYSTEM tables 
> created with namespaces then we get error while creating local or view 
> indexes. If we need to set the namespace enabled or not as for server 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3433) Local or view indexes cannot be created after PHOENIX-3254 if namespaces enabled

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3433:


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

{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 
43 warning messages.

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

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+setUpTestDriver(new 
ReadOnlyProps(serverProps.entrySet().iterator()), new 
ReadOnlyProps(clientProps.entrySet().iterator()));
+try (PhoenixConnection connection = 
QueryUtil.getConnectionOnServer(env.getConfiguration()).unwrap(PhoenixConnection.class);
+try (PhoenixConnection connection = 
QueryUtil.getConnectionOnServer(env.getConfiguration()).unwrap(PhoenixConnection.class)){

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

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

This message is automatically generated.

> Local or view indexes cannot be created after PHOENIX-3254 if namespaces 
> enabled
> 
>
> Key: PHOENIX-3433
> URL: https://issues.apache.org/jira/browse/PHOENIX-3433
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Blocker
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3433.patch
>
>
> As part of PHOENIX-3254 we are trying to create sequences at server while 
> creating local or view indexes. When we try to create a connection we are 
> always going by namespace config false. So by the time if the SYSTEM tables 
> created with namespaces then we get error while creating local or view 
> indexes. If we need to set the namespace enabled or not as for server 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3208) MutationState.toMutations method would throw a exception if multiple tables are upserted

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-3208:


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

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

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{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 
43 warning messages.

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

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+return PhoenixRuntime.JDBC_PROTOCOL + 
PhoenixRuntime.JDBC_PROTOCOL_SEPARATOR + PhoenixRuntime.CONNECTIONLESS;
+conn.createStatement().execute("upsert into 
MUTATION_TEST1(id1,appId1) values(111,'app1')");
+conn.createStatement().execute("upsert into 
MUTATION_TEST2(id2,appId2) values(222,'app2')");
+private void assertTable(String tableName1,List 
keyValues1,String tableName2,List keyValues2) {
+
assertTrue(Bytes.equals(PUnsignedInt.INSTANCE.toBytes(111),CellUtil.cloneRow(keyValues1.get(0;
+
assertTrue("app1".equals(PVarchar.INSTANCE.toObject(CellUtil.cloneValue(keyValues1.get(0);
+
assertTrue(Bytes.equals(PUnsignedInt.INSTANCE.toBytes(222),CellUtil.cloneRow(keyValues2.get(0;
+
assertTrue("app2".equals(PVarchar.INSTANCE.toObject(CellUtil.cloneValue(keyValues2.get(0);

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-[IndexIT_localIndex=true,mutable=true,transactional=true]

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

This message is automatically generated.

> MutationState.toMutations method would throw a exception if multiple tables 
> are upserted 
> -
>
> Key: PHOENIX-3208
> URL: https://issues.apache.org/jira/browse/PHOENIX-3208
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: chenglei
> Attachments: PHOENIX-3208_v4.patch
>
>
> MutationState.toMutations method is to return the current uncommitted 
> tables mutations , but if multiple tables have been upserted , the 
> toMutations method would throw a exception:
> {code:borderStyle=solid}
>  java.util.NoSuchElementException
>   at com.google.common.collect.Iterators$1.next(Iterators.java:77)
>   at 
> org.apache.phoenix.execute.MutationState$1.next(MutationState.java:584)
>   at org.apache.phoenix.execute.MutationState$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:710)
>   at 
> org.apache.phoenix.execute.MutationState$2$1.next(MutationState.java:1)
>   at 
> org.apache.phoenix.execute.MutationState$2.next(MutationState.java:732)
>   at org.apache.phoenix.execute.MutationState$2.next(MutationState.java:1)
>   at 
> org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:354)
>   at org.apache.phoenix.util.PhoenixRuntime$1.next(PhoenixRuntime.java:1)
> {code}
>  
> I write a simple unit test to reproduce this problem in my patch,the 
> PhoenixRuntime.getUncommittedDataIterator method internally uses the  
> MutationState.toMutations method:
> {code:borderStyle=solid} 
> @Test
> public void testToMutationsError() throws Exception {
> Connection conn = null;
> try {
> conn=DriverManager.getConnection(getUrl());
> conn.createStatement().execute(
> "create table MUTATION_TEST1"+
> "( id1 UNSIGNED_INT not null primary key,"+
>   "appId1 VARCHAR)");
> conn.createStatement().execute(
> "create table MUTATION_TEST2"+
> "( id2 UNSIGNED_INT not null primary key,"+
>   "appId2 VARCHAR)");
> conn.createStatement().execute("upsert