[jira] [Updated] (PHOENIX-5734) IndexScrutinyTool should not report rows beyond maxLookBack age

2020-02-21 Thread Swaroopa Kadam (Jira)


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

Swaroopa Kadam updated PHOENIX-5734:

Description: 
Index Scrutiny tool should not report row mismatch if the row gets rewritten 
during the run and the last version around is beyond max look back age which 
will then get removed by compaction. 

 

Or add another type of counters to separate invalid rows into 
BEYOND_MAX_LOOKBACK or similar

  was:Index Scrutiny tool should not report row mismatch if the row gets 
rewritten during the run and the last version around is beyond max look back 
age which will then get removed by compaction. 


> IndexScrutinyTool should not report rows beyond maxLookBack age
> ---
>
> Key: PHOENIX-5734
> URL: https://issues.apache.org/jira/browse/PHOENIX-5734
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Swaroopa Kadam
>Assignee: Swaroopa Kadam
>Priority: Major
>
> Index Scrutiny tool should not report row mismatch if the row gets rewritten 
> during the run and the last version around is beyond max look back age which 
> will then get removed by compaction. 
>  
> Or add another type of counters to separate invalid rows into 
> BEYOND_MAX_LOOKBACK or similar



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (PHOENIX-5734) IndexScrutinyTool should not report rows beyond maxLookBack age

2020-02-21 Thread Swaroopa Kadam (Jira)


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

Swaroopa Kadam updated PHOENIX-5734:

Fix Version/s: 4.16.0

> IndexScrutinyTool should not report rows beyond maxLookBack age
> ---
>
> Key: PHOENIX-5734
> URL: https://issues.apache.org/jira/browse/PHOENIX-5734
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Swaroopa Kadam
>Assignee: Swaroopa Kadam
>Priority: Major
> Fix For: 4.16.0
>
>
> Index Scrutiny tool should not report row mismatch if the row gets rewritten 
> during the run and the last version around is beyond max look back age which 
> will then get removed by compaction. 
>  
> Or add another type of counters to separate invalid rows into 
> BEYOND_MAX_LOOKBACK or similar



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (PHOENIX-5719) testIndexRebuildTask test is failing on pre-commit and master build

2020-02-21 Thread Gokcen Iskender (Jira)


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

Gokcen Iskender updated PHOENIX-5719:
-
Attachment: PHOENIX-5719.master.002.patch

> testIndexRebuildTask test is failing on pre-commit and master build
> ---
>
> Key: PHOENIX-5719
> URL: https://issues.apache.org/jira/browse/PHOENIX-5719
> Project: Phoenix
>  Issue Type: Test
>Reporter: Xinyi Yan
>Assignee: Gokcen Iskender
>Priority: Major
> Attachments: PHOENIX-5719.master.001.patch, 
> PHOENIX-5719.master.002.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> testIndexRebuildTask has been failing for a few days on PreCommit build, as 
> well as master build(first failing on Jan 31).
> [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3401/testReport/]
> [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3393/]
> [https://builds.apache.org/job/PreCommit-PHOENIX-Build/3400/]
> [https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master/2638/]
> [https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master/2639/testReport/]
> Can someone take a look at this flapper test, thanks
> [~kadir] [~gjacoby] [~swaroopa]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

2020-02-21 Thread Sandeep Guggilam (Jira)


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

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: (was: PHOENIX-5607.4.x-HBase-1.3.v3.patch)

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (PHOENIX-5607) Client-server backward compatibility tests

2020-02-21 Thread Sandeep Guggilam (Jira)


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

Sandeep Guggilam updated PHOENIX-5607:
--
Attachment: PHOENIX-5607.4.x-HBase-1.3.v3.patch

> Client-server backward compatibility tests 
> ---
>
> Key: PHOENIX-5607
> URL: https://issues.apache.org/jira/browse/PHOENIX-5607
> Project: Phoenix
>  Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Sandeep Guggilam
>Priority: Blocker
>  Labels: phoenix-hardening
> Fix For: 4.16.0
>
> Attachments: PHOENIX-5607.4.x-HBase-1.3.v1.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v2.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch, PHOENIX-5607.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5607.4.x-HBase-1.3.v3.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' 
> backwards compatibility story is weak, and lacks tests - in fact there're no 
> tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ckulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (PHOENIX-5673) The mutation state is silently getting cleared on the execution of any DDL

2020-02-21 Thread Siddhi Mehta (Jira)


 [ 
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-5709) Simplify index update generation code for consistent global indexes

2020-02-21 Thread Kadir OZDEMIR (Jira)


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

Kadir OZDEMIR updated PHOENIX-5709:
---
Attachment: PHOENIX-5709.4.x-HBase-1.3.007.patch

> Simplify index update generation code for consistent global indexes
> ---
>
> Key: PHOENIX-5709
> URL: https://issues.apache.org/jira/browse/PHOENIX-5709
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.3
>Reporter: Kadir OZDEMIR
>Assignee: Kadir OZDEMIR
>Priority: Major
> Fix For: 5.0.0, 4.14.3
>
> Attachments: PHOENIX-5709.4.x-HBase-1.3.001.patch, 
> PHOENIX-5709.4.x-HBase-1.3.002.patch, PHOENIX-5709.4.x-HBase-1.3.003.patch, 
> PHOENIX-5709.4.x-HBase-1.3.004.patch, PHOENIX-5709.4.x-HBase-1.3.005.patch, 
> PHOENIX-5709.4.x-HBase-1.3.006.patch, PHOENIX-5709.4.x-HBase-1.3.007.patch, 
> PHOENIX-5709.master.001.patch, PHOENIX-5709.master.002.patch, 
> PHOENIX-5709.master.003.patch, PHOENIX-5709.master.004.patch, 
> PHOENIX-5709.master.005.patch, PHOENIX-5709.master.006.patch, 
> PHOENIX-5709.master.007.patch, PHOENIX-5709.master.008.patch, 
> PHOENIX-5709.master.009.patch, PHOENIX-5709.master.010.patch, 
> PHOENIX-5709.master.011.patch, PHOENIX-5709.master.012.patch, 
> PHOENIX-5709.master.013.patch
>
>  Time Spent: 8h 50m
>  Remaining Estimate: 0h
>
> The implementation of the new global index design by PHOENIX-5156 essentially 
> introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. 
> IndexRegionObserver is the counterpart of the existing Indexer coprocessor 
> that the previous global indexing feature uses. It implements the indexing 
> write path. GlobalIndexChecker implements the read verification and read 
> repair that happens on the read path. One of the main objectives of the 
> design behind new global indexing was to leverage as much existing indexing 
> code as possible. This objective has been achieved greatly as the entire 
> index table update generation code implemented by various classes (including 
> PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, 
>  LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is 
> leveraged as it is mainly. This objective has served us well to deliver the 
> new indexing feature quickly. The leveraged code is very complex, over 
> engineered, and inefficient, and is not bug free. It is very hard to 
> maintain. It is time to replace the complex set of classes with something 
> drastically simpler and more efficient for the new design.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)