[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.4.x-HBase-1.3.v7.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.4.x-HBase-1.3.v7.patch, PHOENIX-5673.master.v4.patch,
> PHOENIX-5673.master.v5.patch, PHOENIX-5673.master.v6.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: (was: PHOENIX-5673.4.x-HBase-1.3.v7.patch)
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.master.v4.patch, PHOENIX-5673.master.v5.patch,
> PHOENIX-5673.master.v6.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.4.x-HBase-1.3.v7.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.4.x-HBase-1.3.v7.patch, PHOENIX-5673.master.v4.patch,
> PHOENIX-5673.master.v5.patch, PHOENIX-5673.master.v6.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.master.v6.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.master.v4.patch, PHOENIX-5673.master.v5.patch,
> PHOENIX-5673.master.v6.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.master.v5.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.master.v4.patch, PHOENIX-5673.master.v5.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.master.v4.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch,
> PHOENIX-5673.master.v4.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.4.x-HBase-1.3.v3.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch, PHOENIX-5673.4.x-HBase-1.3.v3.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.4.x-HBase-1.3.v2.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch,
> PHOENIX-5673.4.x-HBase-1.3.v2.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: (was: PHOENIX-5673.4.x-HBase-1.3.v1.patch)
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5673:
--
Attachment: PHOENIX-5673.4.x-HBase-1.3.v1.patch
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5673.4.x-HBase-1.3.v1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-5738) Local index DDL failure leaves behind mutations
Siddhi Mehta created PHOENIX-5738: - Summary: Local index DDL failure leaves behind mutations Key: PHOENIX-5738 URL: https://issues.apache.org/jira/browse/PHOENIX-5738 Project: Phoenix Issue Type: Bug Affects Versions: 4.15.0 Reporter: Siddhi Mehta Steps to reproduce: # create table example (id integer not null,fn varchar,\"ln\" varchar constraint pk primary key(id)) DEFAULT_COLUMN_FAMILY='F') # create local index my_idx on example (fn) DEFAULT_COLUMN_FAMILY='F' # When we execute the index creation it will fail due to 'Default column family not allowed on VIEW or shared INDEX.' If you do a conn.commit() and look the mutations on the connection you will see mutation left behind -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-4521) Allow Pherf scenario to define per table max allowed query duration after which thread is interrupted
[ https://issues.apache.org/jira/browse/PHOENIX-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta reassigned PHOENIX-4521: - Assignee: Christine Feng > Allow Pherf scenario to define per table max allowed query duration after > which thread is interrupted > - > > Key: PHOENIX-4521 > URL: https://issues.apache.org/jira/browse/PHOENIX-4521 > Project: Phoenix > Issue Type: Improvement >Reporter: James R. Taylor >Assignee: Christine Feng >Priority: Major > Labels: phoenix-hardening > > Some clients interrupt the client thread if it doesn't complete in a required > amount of time. It would be good if Pherf supported setting this up so we > mimic client behavior more closely, as we're theorizing this may be causing > some issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL
[
https://issues.apache.org/jira/browse/PHOENIX-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta reassigned PHOENIX-5673:
-
Assignee: Siddhi Mehta
> The mutation state is silently getting cleared on the execution of any DDL
> --
>
> Key: PHOENIX-5673
> URL: https://issues.apache.org/jira/browse/PHOENIX-5673
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Siddhi Mehta
>Priority: Critical
> Labels: beginner, newbie
> Fix For: 4.16.0
>
>
> When we execute any DDL statement, the mutations state is rolled back
> silently without informing the user. It should probably throw an exception
> saying that the mutation state is not empty when executing any DDL. See the
> below example:
>
> Steps to reproduce:
> create table t1 (pk varchar not null primary key, mycol varchar)
> upsert into t1 (pk, mycol) values ('x','x');
> create table t2 (pk varchar not null primary key, mycol varchar)
> When we try to execute the above statements and do a conn.commit() at the
> end, it would silently rollback the upsert statement when we execute the
> second create statement and you wouldn't see the ('x', 'x') values in the
> first table. Instead it should probably throw an exception saying that the
> mutation state is not empty
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5044) Remove server side mutation code from Phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-5044: -- Labels: phoenix-hardening (was: ) > Remove server side mutation code from Phoenix > - > > Key: PHOENIX-5044 > URL: https://issues.apache.org/jira/browse/PHOENIX-5044 > Project: Phoenix > Issue Type: Task >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > Labels: phoenix-hardening > Attachments: 5044-looksee-v2.txt, 5044-looksee-v3.txt, > 5044-looksee.txt > > > This is for *discussion*. Perhaps controversial. > It generally seems to be a bad - if well-intentioned - idea to trigger > mutations directly from the server. The main causes are UPSERT SELECT for the > same table and DELETE FROM. > IMHO, it's generally better to allow the client to handle this. There might > be larger network overhead, but we get better chunking, better pacing, and > behavior more in line with how HBase was intended to work. > In PHOENIX-5026 I introduced a flag to disable server triggered mutations in > the two cases mentioned above. I now think it's better to just remove the > server code and also perform these from the client. > (Note that server side reads - aggregation, filters, etc - are still insanely > valuable and not affected by this) > Let's discuss. > [~tdsilva], [~an...@apache.org], [~jamestaylor], [~vincentpoon], [~gjacoby] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5672) Unable to find cached index metadata with large UPSERT/SELECT and local index.
[
https://issues.apache.org/jira/browse/PHOENIX-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-5672:
--
Labels: phoenix-hardening (was: )
> Unable to find cached index metadata with large UPSERT/SELECT and local index.
> --
>
> Key: PHOENIX-5672
> URL: https://issues.apache.org/jira/browse/PHOENIX-5672
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Priority: Major
> Labels: phoenix-hardening
>
> Doing a very large UPSERT/SELECT back into the same table. After a while I
> get this exception. This happens with server side mutation turned off or on
> and regardless of the batch-size (which I have increased to 1 in this
> last example).
> {code:java}
> 20/01/10 16:41:54 WARN client.AsyncProcess: #1, table=TEST, attempt=1/35
> failed=1ops, last exception:
> org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: ERROR 2008 (INT10): ERROR 2008
> (INT10): Unable to find cached index metadata. key=-1180967500149768360
> region=TEST,\x80\x965g\x80\x0F@\xAA\x80Y$\xEF,1578504217187.42467236e0b49fda05fdaaf69de98832.host=lhofhansl-wsl2,16201,157870268
> Index update failed20/01/10 16:41:54 WARN client.AsyncProcess: #1,
> table=TEST, attempt=1/35 failed=1ops, last exception:
> org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: ERROR 2008 (INT10): ERROR 2008
> (INT10): Unable to find cached index metadata. key=-1180967500149768360
> region=TEST,\x80\x965g\x80\x0F@\xAA\x80Y$\xEF,1578504217187.42467236e0b49fda05fdaaf69de98832.host=lhofhansl-wsl2,16201,157870268
> Index update failed at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:113) at
> org.apache.phoenix.util.ServerUtil.throwIOException(ServerUtil.java:87) at
> org.apache.phoenix.index.PhoenixIndexMetaDataBuilder.getIndexMetaDataCache(PhoenixIndexMetaDataBuilder.java:101)
> at
> org.apache.phoenix.index.PhoenixIndexMetaDataBuilder.getIndexMetaData(PhoenixIndexMetaDataBuilder.java:51)
> at
> org.apache.phoenix.index.PhoenixIndexBuilder.getIndexMetaData(PhoenixIndexBuilder.java:100)
> at
> org.apache.phoenix.index.PhoenixIndexBuilder.getIndexMetaData(PhoenixIndexBuilder.java:73)
> at
> org.apache.phoenix.hbase.index.builder.IndexBuildManager.getIndexMetaData(IndexBuildManager.java:84)
> at
> org.apache.phoenix.hbase.index.IndexRegionObserver.getPhoenixIndexMetaData(IndexRegionObserver.java:594)
> at
> org.apache.phoenix.hbase.index.IndexRegionObserver.preBatchMutateWithExceptions(IndexRegionObserver.java:646)
> at
> org.apache.phoenix.hbase.index.IndexRegionObserver.preBatchMutate(IndexRegionObserver.java:334)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$35.call(RegionCoprocessorHost.java:1024)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1742)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1827)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1783)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preBatchMutate(RegionCoprocessorHost.java:1020)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:3425)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3163)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3105)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:944)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:872)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2472)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:36812)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2399) at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124) at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:311) at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:291)Caused
> by: java.sql.SQLException: ERROR 2008 (INT10): Unable to find cached index
> metadata. key=-1180967500149768360
> region=TEST,\x80\x965g\x80\x0F@\xAA\x80Y$\xEF,1578504217187.42467236e0b49fda05fdaaf69de98832.host=lhofhansl-wsl2,16201,157870268
> at
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:542)
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
> at
[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
[ https://issues.apache.org/jira/browse/PHOENIX-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626013#comment-15626013 ] Siddhi Mehta commented on PHOENIX-3427: --- [~giacomotaylor],[~elserj] Thoughts? > 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] [Updated] (PHOENIX-2367) Change PhoenixRecordWriter to use execute instead of executeBatch
[ https://issues.apache.org/jira/browse/PHOENIX-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-2367: -- Attachment: PHOENIX-2367.patch [~giacomotaylor],[~jfernando_sfdc],[~prkommireddi],[~maghamraviki...@gmail.com] Can you guys review the change. I ran phoenix-pig tests. Any other tests I should be running? > Change PhoenixRecordWriter to use execute instead of executeBatch > - > > Key: PHOENIX-2367 > URL: https://issues.apache.org/jira/browse/PHOENIX-2367 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta > Attachments: PHOENIX-2367.patch > > > Hey All, > I wanted to add a notion of skipping invalid rows for PhoenixHbaseStorage > similar to how the CSVBulkLoad tool has an option of ignoring the bad rows.I > did some work on the apache pig code that allows Storers to have a notion of > Customizable/Configurable Errors PIG-4704. > I wanted to plug this behavior for PhoenixHbaseStorage and propose certain > changes for the same. > Current Behavior/Problem: > PhoenixRecordWriter makes use of executeBatch() to process rows once batch > size is reached. If there are any client side validation/syntactical errors > like data not fitting the column size, executeBatch() throws an exception and > there is no-way to retrieve the valid rows from the batch and retry them. We > discard the whole batch or fail the job without errorhandling. > With auto commit set to false execute() also servers the purpose of not > making any rpc calls but does a bunch of validation client side and adds it > to the client cache of mutation. > On conn.commit() we make a rpc call. > Proposed Change > To be able to use Configurable ErrorHandling and ignore only the failed > records instead of discarding the whole batch I want to propose changing the > behavior in PhoenixRecordWriter from execute to executeBatch() or having a > configuration to toggle between the 2 behaviors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2510) ReserveNSequence opens new connection per invocation
[
https://issues.apache.org/jira/browse/PHOENIX-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059148#comment-15059148
]
Siddhi Mehta commented on PHOENIX-2510:
---
[~jamestaylor] Yes ran the pig tests that make use of the udf
> ReserveNSequence opens new connection per invocation
>
>
> Key: PHOENIX-2510
> URL: https://issues.apache.org/jira/browse/PHOENIX-2510
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Siddhi Mehta
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2510.patch
>
>
> Happened to be looking at this code and I noticed that a connection member
> variable is set for each call to exec by calling
> ConnectionUtil.getOutputConnection regardless of the initialization code
> above it. Doesn't look right to me.
> {code}
> @Override
> public Long exec(Tuple input) throws IOException {
> Preconditions.checkArgument(input != null && input.size() >= 2,
> INVALID_TUPLE_MESSAGE);
> Long numToReserve = (Long)(input.get(0));
> Preconditions.checkArgument(numToReserve > 0, INVALID_NUMBER_MESSAGE);
> String sequenceName = (String)input.get(1);
> Preconditions.checkNotNull(sequenceName, EMPTY_SEQUENCE_NAME_MESSAGE);
> // It will create a connection when called for the first Tuple per
> task.
> // The connection gets cleaned up in finish() method
> if (connection == null) {
> initConnection();
> }
> ResultSet rs = null;
> try {
> connection = ConnectionUtil.getOutputConnection(configuration);
> String sql =
> getNextNSequenceSelectStatement(Long.valueOf(numToReserve), sequenceName);
> rs = connection.createStatement().executeQuery(sql);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2510) ReserveNSequence opens new connection per invocation
[
https://issues.apache.org/jira/browse/PHOENIX-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddhi Mehta updated PHOENIX-2510:
--
Attachment: PHOENIX-2510.patch
[~giacomotaylor] Thanks for noticing the issue.
Bad cleanup for the last commit
I made the following changes
1. Remove creating a connection member per invocation.It will not create it
once per task for the first invocation
2. Remove the finally from the exec() method to close connection. Connection
will be close in the finish() method.
3. Updated the test to call udf.finish() to close the connection
> ReserveNSequence opens new connection per invocation
>
>
> Key: PHOENIX-2510
> URL: https://issues.apache.org/jira/browse/PHOENIX-2510
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Siddhi Mehta
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2510.patch
>
>
> Happened to be looking at this code and I noticed that a connection member
> variable is set for each call to exec by calling
> ConnectionUtil.getOutputConnection regardless of the initialization code
> above it. Doesn't look right to me.
> {code}
> @Override
> public Long exec(Tuple input) throws IOException {
> Preconditions.checkArgument(input != null && input.size() >= 2,
> INVALID_TUPLE_MESSAGE);
> Long numToReserve = (Long)(input.get(0));
> Preconditions.checkArgument(numToReserve > 0, INVALID_NUMBER_MESSAGE);
> String sequenceName = (String)input.get(1);
> Preconditions.checkNotNull(sequenceName, EMPTY_SEQUENCE_NAME_MESSAGE);
> // It will create a connection when called for the first Tuple per
> task.
> // The connection gets cleaned up in finish() method
> if (connection == null) {
> initConnection();
> }
> ResultSet rs = null;
> try {
> connection = ConnectionUtil.getOutputConnection(configuration);
> String sql =
> getNextNSequenceSelectStatement(Long.valueOf(numToReserve), sequenceName);
> rs = connection.createStatement().executeQuery(sql);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2367) Change PhoenixRecordWriter to use execute instead of executeBatch
[ https://issues.apache.org/jira/browse/PHOENIX-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-2367: -- Attachment: PHOENIX-2367_2.patch My bad.Uploading a new patch. Ran the phoenix-spark tests and they all passed. > Change PhoenixRecordWriter to use execute instead of executeBatch > - > > Key: PHOENIX-2367 > URL: https://issues.apache.org/jira/browse/PHOENIX-2367 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta > Fix For: 4.7.0 > > Attachments: PHOENIX-2367.patch, PHOENIX-2367_2.patch > > > Hey All, > I wanted to add a notion of skipping invalid rows for PhoenixHbaseStorage > similar to how the CSVBulkLoad tool has an option of ignoring the bad rows.I > did some work on the apache pig code that allows Storers to have a notion of > Customizable/Configurable Errors PIG-4704. > I wanted to plug this behavior for PhoenixHbaseStorage and propose certain > changes for the same. > Current Behavior/Problem: > PhoenixRecordWriter makes use of executeBatch() to process rows once batch > size is reached. If there are any client side validation/syntactical errors > like data not fitting the column size, executeBatch() throws an exception and > there is no-way to retrieve the valid rows from the batch and retry them. We > discard the whole batch or fail the job without errorhandling. > With auto commit set to false execute() also servers the purpose of not > making any rpc calls but does a bunch of validation client side and adds it > to the client cache of mutation. > On conn.commit() we make a rpc call. > Proposed Change > To be able to use Configurable ErrorHandling and ignore only the failed > records instead of discarding the whole batch I want to propose changing the > behavior in PhoenixRecordWriter from execute to executeBatch() or having a > configuration to toggle between the 2 behaviors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2373) Change ReserveNSequence Udf to take in zookeeper and tentantId as param
[ https://issues.apache.org/jira/browse/PHOENIX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994423#comment-14994423 ] Siddhi Mehta commented on PHOENIX-2373: --- [~maghamraviki...@gmail.com] The Apache license header was placed after package declaration in ReserveNSequence.java. I moved it up to before the package declaration. Is that incorrect order? > Change ReserveNSequence Udf to take in zookeeper and tentantId as param > --- > > Key: PHOENIX-2373 > URL: https://issues.apache.org/jira/browse/PHOENIX-2373 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta >Priority: Minor > Attachments: PHOENIX-2373.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently the UDF reads zookeeper quorum for tuple value and tenantId is > passed in from the jobConf. > Instead wanted to make a change for the UDF to take both zookeeper quorum and > tenantId as params passed to the UDF explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2373) Change ReserveNSequence Udf to take in zookeeper and tentantId as param
[ https://issues.apache.org/jira/browse/PHOENIX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-2373: -- Attachment: PHOENIX-2373.patch [~prkommireddi],[~maghamraviki...@gmail.com],[~jfernando_sfdc],[~giacomotaylor] Mind reviewing the patch? 1. I have changed the udf to take zkQuorum and tentantId in constructor og udf. 2. Optimized the udf to make only 1 connection per task instead of 1 per tuple 3. Changes to test for tentant specifc and generic connection udf. > Change ReserveNSequence Udf to take in zookeeper and tentantId as param > --- > > Key: PHOENIX-2373 > URL: https://issues.apache.org/jira/browse/PHOENIX-2373 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta >Priority: Minor > Attachments: PHOENIX-2373.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Currently the UDF reads zookeeper quorum for tuple value and tenantId is > passed in from the jobConf. > Instead wanted to make a change for the UDF to take both zookeeper quorum and > tenantId as params passed to the UDF explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2367) Change PhoenixRecordWriter to use execute instead of executeBatch
[ https://issues.apache.org/jira/browse/PHOENIX-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14990554#comment-14990554 ] Siddhi Mehta commented on PHOENIX-2367: --- [~jmahonin] I believe there is no performance overhead for the same. [~giacomotaylor],[~maghamraviki...@gmail.com],[~jfernando_sfdc] Thoughts on the same? We can make this change configurable based on a property value. How about phoenix.record.writer.batch.execute with it being set to default true for existing behaviour > Change PhoenixRecordWriter to use execute instead of executeBatch > - > > Key: PHOENIX-2367 > URL: https://issues.apache.org/jira/browse/PHOENIX-2367 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta > > Hey All, > I wanted to add a notion of skipping invalid rows for PhoenixHbaseStorage > similar to how the CSVBulkLoad tool has an option of ignoring the bad rows.I > did some work on the apache pig code that allows Storers to have a notion of > Customizable/Configurable Errors PIG-4704. > I wanted to plug this behavior for PhoenixHbaseStorage and propose certain > changes for the same. > Current Behavior/Problem: > PhoenixRecordWriter makes use of executeBatch() to process rows once batch > size is reached. If there are any client side validation/syntactical errors > like data not fitting the column size, executeBatch() throws an exception and > there is no-way to retrieve the valid rows from the batch and retry them. We > discard the whole batch or fail the job without errorhandling. > With auto commit set to false execute() also servers the purpose of not > making any rpc calls but does a bunch of validation client side and adds it > to the client cache of mutation. > On conn.commit() we make a rpc call. > Proposed Change > To be able to use Configurable ErrorHandling and ignore only the failed > records instead of discarding the whole batch I want to propose changing the > behavior in PhoenixRecordWriter from execute to executeBatch() or having a > configuration to toggle between the 2 behaviors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2373) Change ReserveNSequence Udf to take in zookeeper and tentantId as param
[ https://issues.apache.org/jira/browse/PHOENIX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddhi Mehta updated PHOENIX-2373: -- Remaining Estimate: 24h (was: 1m) Original Estimate: 24h (was: 1m) > Change ReserveNSequence Udf to take in zookeeper and tentantId as param > --- > > Key: PHOENIX-2373 > URL: https://issues.apache.org/jira/browse/PHOENIX-2373 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > Currently the UDF reads zookeeper quorum for tuple value and tenantId is > passed in from the jobConf. > Instead wanted to make a change for the UDF to take both zookeeper quorum and > tenantId as params passed to the UDF explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2373) Change ReserveNSequence Udf to take in zookeeper and tentantId as param
Siddhi Mehta created PHOENIX-2373: - Summary: Change ReserveNSequence Udf to take in zookeeper and tentantId as param Key: PHOENIX-2373 URL: https://issues.apache.org/jira/browse/PHOENIX-2373 Project: Phoenix Issue Type: Improvement Reporter: Siddhi Mehta Assignee: Siddhi Mehta Priority: Minor Currently the UDF reads zookeeper quorum for tuple value and tenantId is passed in from the jobConf. Instead wanted to make a change for the UDF to take both zookeeper quorum and tenantId as params passed to the UDF explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2373) Change ReserveNSequence Udf to take in zookeeper and tentantId as param
[ https://issues.apache.org/jira/browse/PHOENIX-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14990703#comment-14990703 ] Siddhi Mehta commented on PHOENIX-2373: --- This is related to the previous Jira where we added a pig udf to bulk reserve sequences. An enhancement to the udf https://issues.apache.org/jira/browse/PHOENIX-2098 [~giacomotaylor],[~jfernando_sfdc] > Change ReserveNSequence Udf to take in zookeeper and tentantId as param > --- > > Key: PHOENIX-2373 > URL: https://issues.apache.org/jira/browse/PHOENIX-2373 > Project: Phoenix > Issue Type: Improvement >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta >Priority: Minor > Original Estimate: 1m > Remaining Estimate: 1m > > Currently the UDF reads zookeeper quorum for tuple value and tenantId is > passed in from the jobConf. > Instead wanted to make a change for the UDF to take both zookeeper quorum and > tenantId as params passed to the UDF explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2367) Change PhoenixRecordWriter to use execute instead of executeBatch
Siddhi Mehta created PHOENIX-2367: - Summary: Change PhoenixRecordWriter to use execute instead of executeBatch Key: PHOENIX-2367 URL: https://issues.apache.org/jira/browse/PHOENIX-2367 Project: Phoenix Issue Type: Improvement Reporter: Siddhi Mehta Assignee: Siddhi Mehta Hey All, I wanted to add a notion of skipping invalid rows for PhoenixHbaseStorage similar to how the CSVBulkLoad tool has an option of ignoring the bad rows.I did some work on the apache pig code that allows Storers to have a notion of Customizable/Configurable Errors PIG-4704. I wanted to plug this behavior for PhoenixHbaseStorage and propose certain changes for the same. Current Behavior/Problem: PhoenixRecordWriter makes use of executeBatch() to process rows once batch size is reached. If there are any client side validation/syntactical errors like data not fitting the column size, executeBatch() throws an exception and there is no-way to retrieve the valid rows from the batch and retry them. We discard the whole batch or fail the job without errorhandling. With auto commit set to false execute() also servers the purpose of not making any rpc calls but does a bunch of validation client side and adds it to the client cache of mutation. On conn.commit() we make a rpc call. Proposed Change To be able to use Configurable ErrorHandling and ignore only the failed records instead of discarding the whole batch I want to propose changing the behavior in PhoenixRecordWriter from execute to executeBatch() or having a configuration to toggle between the 2 behaviors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2098) Pig Udf that given a count Reserve chunks of numbers for a sequence
[ https://issues.apache.org/jira/browse/PHOENIX-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617626#comment-14617626 ] Siddhi Mehta commented on PHOENIX-2098: --- [~giacomotaylor],[~jfernando_sfdc] I have a working version for this. https://github.com/siddhimehta/phoenix/commit/7ec6bbad40b0c9cbe61ff099f910fb85144029e6 I was going to wait on PHOENIX-1954 to be commited before I start a pull request. Let me know if I should start the pull request. Pig Udf that given a count Reserve chunks of numbers for a sequence --- Key: PHOENIX-2098 URL: https://issues.apache.org/jira/browse/PHOENIX-2098 Project: Phoenix Issue Type: New Feature Reporter: Siddhi Mehta Assignee: Siddhi Mehta Following up on the Jira to bulk reserve sequence's. PHOENIX-1954. Adding a UDF to enable bulk reserve of sequence's from Pig -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2098) Pig Udf that given a count Reserve chunks of numbers for a sequence
[ https://issues.apache.org/jira/browse/PHOENIX-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613378#comment-14613378 ] Siddhi Mehta commented on PHOENIX-2098: --- Thanks [~giacomotaylor]. Wasn't aware of PHOENIX-922. Will definitely take advantage of it. Pig Udf that given a count Reserve chunks of numbers for a sequence --- Key: PHOENIX-2098 URL: https://issues.apache.org/jira/browse/PHOENIX-2098 Project: Phoenix Issue Type: New Feature Reporter: Siddhi Mehta Assignee: Siddhi Mehta Following up on the Jira to bulk reserve sequence's. PHOENIX-1954. Adding a UDF to enable bulk reserve of sequence's from Pig -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2098) Pig Udf that given a count Reserve chunks of numbers for a sequence
Siddhi Mehta created PHOENIX-2098: - Summary: Pig Udf that given a count Reserve chunks of numbers for a sequence Key: PHOENIX-2098 URL: https://issues.apache.org/jira/browse/PHOENIX-2098 Project: Phoenix Issue Type: New Feature Reporter: Siddhi Mehta Following up on the Jira to bulk reserve sequence's. PHOENIX-1954. Adding a UDF to enable bulk reserve of sequence's from Pig -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2036) PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime
[
https://issues.apache.org/jira/browse/PHOENIX-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598535#comment-14598535
]
Siddhi Mehta commented on PHOENIX-2036:
---
[~giacomotaylor] , [~maghamravi] Not sure if this will work for the
PhoenixHBaseStorage usecase
We need the case sensitive table name for the upsert statements.(e.g UPSERT
into CUSTOM_ENTITY.z02 VALUES ...)
With the patch the OUTPUT_TABLE_NAME is case sensitive but not enclosed in
quotes ( CUSTOM_ENTITY.z02)
We will correctly generate the columnMetadataList by passing in the case
sensitive not enclosed in quotes table name
but the upsert statement generated will be incorrect. (e.g UPSERT into
CUSTOM_ENTITY.z02 VALUES ...)
{code}
public static String getUpsertStatement(final Configuration configuration)
throws SQLException {
...
upsertStmt = QueryUtil.constructUpsertStatement(tableName,
columnMetadataList);
return upsertStmt;
}
{code}
Either we need to make QueryUtil.constructUpsertStatement be aware of this
change or push down the change to
org.apache.phoenix.mapreduce.util.PhoenixConfigurationUtil.getUpsertColumnMetadataList(Configuration)
PhoenixConfigurationUtil should provide a pre-normalize table name to
PhoenixRuntime
Key: PHOENIX-2036
URL: https://issues.apache.org/jira/browse/PHOENIX-2036
Project: Phoenix
Issue Type: Bug
Reporter: Siddhi Mehta
Priority: Minor
Attachments: PHOENIX-2036-v1.patch, PHOENIX-2036.patch
Original Estimate: 24h
Remaining Estimate: 24h
I was trying a basic store using PhoenixHBaseStorage and ran into some issues
with it complaining about TableNotFoundException.
The table(CUSTOM_ENTITY.z02) in question exists.
Looking at the stacktrace I think its likely related to the change in
PHOENIX-1682 where phoenix runtime expects a pre-normalized table name.
We need to update
PhoenixConfigurationUtil.getSelectColumnMetadataList(Configuration) be pass a
pre-normalized table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PHOENIX-2036) PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime
Siddhi Mehta created PHOENIX-2036: - Summary: PhoenixConfigurationUtil should provide a pre-normalize table name to PhoenixRuntime Key: PHOENIX-2036 URL: https://issues.apache.org/jira/browse/PHOENIX-2036 Project: Phoenix Issue Type: Bug Reporter: Siddhi Mehta Priority: Minor I was trying a basic store using PhoenixHBaseStorage and ran into some issues with it complaining about TableNotFoundException. The table(CUSTOM_ENTITY.z02) in question exists. Looking at the stacktrace I think its likely related to the change in PHOENIX-1682 where phoenix runtime expects a pre-normalized table name. We need to update PhoenixConfigurationUtil.getSelectColumnMetadataList(Configuration) be pass a pre-normalized table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
