[jira] [Assigned] (PHOENIX-4270) IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot after runs
[ https://issues.apache.org/jira/browse/PHOENIX-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-4270: --- Assignee: (was: churro morales) > IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot > after runs > --- > > Key: PHOENIX-4270 > URL: https://issues.apache.org/jira/browse/PHOENIX-4270 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales > Attachments: PHOENIX-4270.patch > > > If the IndexTool or IndexScrutiny tool run with the snapshot option and the > timestamp is before the hbase.regionserver.optionalcacheflushinterval then > they should skip flushing as whatever is in the memstore will not be read by > the scanners and takes extra overhead. > Additionally both of these jobs should cleanup their snapshots after they > complete or this will take up dfs capacity unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PHOENIX-3711) Convert static methods which create PTables in PTableImpl to a Builder pattern
[ https://issues.apache.org/jira/browse/PHOENIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales closed PHOENIX-3711. --- > Convert static methods which create PTables in PTableImpl to a Builder pattern > -- > > Key: PHOENIX-3711 > URL: https://issues.apache.org/jira/browse/PHOENIX-3711 > Project: Phoenix > Issue Type: Task >Reporter: churro morales >Assignee: churro morales > > It will be nice to use a builder pattern such that we do not have to > constantly create static methods for one-off creations of our PTables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-3711) Convert static methods which create PTables in PTableImpl to a Builder pattern
[ https://issues.apache.org/jira/browse/PHOENIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-3711: --- Assignee: (was: churro morales) > Convert static methods which create PTables in PTableImpl to a Builder pattern > -- > > Key: PHOENIX-3711 > URL: https://issues.apache.org/jira/browse/PHOENIX-3711 > Project: Phoenix > Issue Type: Task >Reporter: churro morales > > It will be nice to use a builder pattern such that we do not have to > constantly create static methods for one-off creations of our PTables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4323) LocalIndexes could fail if your data row is not in the same region as your index region
[ https://issues.apache.org/jira/browse/PHOENIX-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-4323: --- Assignee: Vincent Poon > LocalIndexes could fail if your data row is not in the same region as your > index region > --- > > Key: PHOENIX-4323 > URL: https://issues.apache.org/jira/browse/PHOENIX-4323 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: Vincent Poon > Attachments: LocalIndexIT.java > > > This is not likely to happen, but if this does your data table and index > write will never succeed. > In HRegion.doMiniBatchMutation() > You create index rows in the preBatchMutate() then when you call checkRow() > on that index row the exception will bubble up if the index row is not in the > same region as your data row. > Like I said this is unlikely, but you would have to do a region merge to fix > this issue if encountered. > [~vincentpoon] has a test which he will attach to this JIRA showing an > example how this can happen. The write will never succeed unless you merge > regions if this ever happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4323) LocalIndexes could fail if your data row is not in the same region as your index region
churro morales created PHOENIX-4323: --- Summary: LocalIndexes could fail if your data row is not in the same region as your index region Key: PHOENIX-4323 URL: https://issues.apache.org/jira/browse/PHOENIX-4323 Project: Phoenix Issue Type: Bug Reporter: churro morales This is not likely to happen, but if this does your data table and index write will never succeed. In HRegion.doMiniBatchMutation() You create index rows in the preBatchMutate() then when you call checkRow() on that index row the exception will bubble up if the index row is not in the same region as your data row. Like I said this is unlikely, but you would have to do a region merge to fix this issue if encountered. [~vincentpoon] has a test which he will attach to this JIRA showing an example how this can happen. The write will never succeed unless you merge regions if this ever happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4269) IndexScrutinyToolIT is flapping
[
https://issues.apache.org/jira/browse/PHOENIX-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191830#comment-16191830
]
churro morales commented on PHOENIX-4269:
-
+1 lgtm
> IndexScrutinyToolIT is flapping
> ---
>
> Key: PHOENIX-4269
> URL: https://issues.apache.org/jira/browse/PHOENIX-4269
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: James Taylor
>Assignee: Vincent Poon
> Attachments: PHOENIX-4269.master.patch
>
>
> In a local test run (not able to repro when run separately), I saw the
> following failure:
> {code}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 193.228 s <<< FAILURE! - in org.apache.phoenix.end2end.IndexScrutinyToolIT
> [ERROR]
> testBothDataAndIndexAsSource[0](org.apache.phoenix.end2end.IndexScrutinyToolIT)
> Time elapsed: 11.708 s <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at
> org.apache.phoenix.end2end.IndexScrutinyToolIT.testBothDataAndIndexAsSource(IndexScrutinyToolIT.java:344)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4269) IndexScrutinyToolIT is flapping
[
https://issues.apache.org/jira/browse/PHOENIX-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191782#comment-16191782
]
churro morales commented on PHOENIX-4269:
-
Looks like [~vincentpoon] figured out that this was due to how timestamps were
set in the test. He will be putting up a patch shortly which fixes these
issues. Great work and thank you!
> IndexScrutinyToolIT is flapping
> ---
>
> Key: PHOENIX-4269
> URL: https://issues.apache.org/jira/browse/PHOENIX-4269
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: churro morales
>
> In a local test run (not able to repro when run separately), I saw the
> following failure:
> {code}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 193.228 s <<< FAILURE! - in org.apache.phoenix.end2end.IndexScrutinyToolIT
> [ERROR]
> testBothDataAndIndexAsSource[0](org.apache.phoenix.end2end.IndexScrutinyToolIT)
> Time elapsed: 11.708 s <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at
> org.apache.phoenix.end2end.IndexScrutinyToolIT.testBothDataAndIndexAsSource(IndexScrutinyToolIT.java:344)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4270) IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot after runs
[ https://issues.apache.org/jira/browse/PHOENIX-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4270: Attachment: PHOENIX-4270.patch [~vincentpoon] or [~jamestaylor] care to take a look at this patch? > IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot > after runs > --- > > Key: PHOENIX-4270 > URL: https://issues.apache.org/jira/browse/PHOENIX-4270 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: churro morales > Attachments: PHOENIX-4270.patch > > > If the IndexTool or IndexScrutiny tool run with the snapshot option and the > timestamp is before the hbase.regionserver.optionalcacheflushinterval then > they should skip flushing as whatever is in the memstore will not be read by > the scanners and takes extra overhead. > Additionally both of these jobs should cleanup their snapshots after they > complete or this will take up dfs capacity unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4270) IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot after runs
churro morales created PHOENIX-4270: --- Summary: IndexTool and IndexScrutiny Tool should optionally flush and delete snapshot after runs Key: PHOENIX-4270 URL: https://issues.apache.org/jira/browse/PHOENIX-4270 Project: Phoenix Issue Type: Bug Reporter: churro morales Assignee: churro morales If the IndexTool or IndexScrutiny tool run with the snapshot option and the timestamp is before the hbase.regionserver.optionalcacheflushinterval then they should skip flushing as whatever is in the memstore will not be read by the scanners and takes extra overhead. Additionally both of these jobs should cleanup their snapshots after they complete or this will take up dfs capacity unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186313#comment-16186313 ] churro morales commented on PHOENIX-4238: - [~jamestaylor] added local index parameterized test. > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch, PHOENIX-4238.v1.patch, > PHOENIX-4238.v2.patch, PHOENIX-4238.v3.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4238: Attachment: PHOENIX-4238.v3.patch > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch, PHOENIX-4238.v1.patch, > PHOENIX-4238.v2.patch, PHOENIX-4238.v3.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4214) Scans which write should not block region split or close
[ https://issues.apache.org/jira/browse/PHOENIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4214: Attachment: (was: PHOENIX-4238.v3.patch) > Scans which write should not block region split or close > > > Key: PHOENIX-4214 > URL: https://issues.apache.org/jira/browse/PHOENIX-4214 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Fix For: 4.12.0 > > Attachments: PHOENIX-4214-0.98-v2.patch, > PHOENIX-4214-4.x-HBase-0.98_v1.patch, PHOENIX-4214.master.v1.patch, > PHOENIX-4214.master.v2.patch, splitDuringUpsertSelect_wip.patch > > > PHOENIX-3111 introduced a scan reference counter which is checked during > region preSplit and preClose. However, a steady stream of UPSERT SELECT or > DELETE can keep the count above 0 indefinitely, preventing or greatly > delaying a region split or close. > We should try to avoid starvation of the split / close request, and > fail/reject queries where appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4214) Scans which write should not block region split or close
[ https://issues.apache.org/jira/browse/PHOENIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4214: Attachment: PHOENIX-4238.v3.patch added local index parameterized test. > Scans which write should not block region split or close > > > Key: PHOENIX-4214 > URL: https://issues.apache.org/jira/browse/PHOENIX-4214 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Fix For: 4.12.0 > > Attachments: PHOENIX-4214-0.98-v2.patch, > PHOENIX-4214-4.x-HBase-0.98_v1.patch, PHOENIX-4214.master.v1.patch, > PHOENIX-4214.master.v2.patch, splitDuringUpsertSelect_wip.patch > > > PHOENIX-3111 introduced a scan reference counter which is checked during > region preSplit and preClose. However, a steady stream of UPSERT SELECT or > DELETE can keep the count above 0 indefinitely, preventing or greatly > delaying a region split or close. > We should try to avoid starvation of the split / close request, and > fail/reject queries where appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PHOENIX-4214) Scans which write should not block region split or close
[ https://issues.apache.org/jira/browse/PHOENIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186311#comment-16186311 ] churro morales edited comment on PHOENIX-4214 at 9/29/17 7:56 PM: -- sorry attached patch to wrong ticket. was (Author: churromorales): added local index parameterized test. > Scans which write should not block region split or close > > > Key: PHOENIX-4214 > URL: https://issues.apache.org/jira/browse/PHOENIX-4214 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Fix For: 4.12.0 > > Attachments: PHOENIX-4214-0.98-v2.patch, > PHOENIX-4214-4.x-HBase-0.98_v1.patch, PHOENIX-4214.master.v1.patch, > PHOENIX-4214.master.v2.patch, splitDuringUpsertSelect_wip.patch > > > PHOENIX-3111 introduced a scan reference counter which is checked during > region preSplit and preClose. However, a steady stream of UPSERT SELECT or > DELETE can keep the count above 0 indefinitely, preventing or greatly > delaying a region split or close. > We should try to avoid starvation of the split / close request, and > fail/reject queries where appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4238: Attachment: PHOENIX-4238.v2.patch Added the extra check for viewIndexId column. > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch, PHOENIX-4238.v1.patch, > PHOENIX-4238.v2.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186197#comment-16186197 ] churro morales commented on PHOENIX-4238: - Thank you for the review [~vincentpoon] > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch, PHOENIX-4238.v1.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4238: Attachment: PHOENIX-4238.v1.patch Oops forgot to fix one test, this patch should be good. > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch, PHOENIX-4238.v1.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186132#comment-16186132 ] churro morales commented on PHOENIX-4238: - [~jamestaylor] Ask and you shall receive, hope this made it in time. > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4238: Attachment: PHOENIX-4238.patch > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > Attachments: PHOENIX-4238.patch > > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4238) MR IndexScrutinyTool break with salted tables and indexes on views
[ https://issues.apache.org/jira/browse/PHOENIX-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16185308#comment-16185308 ] churro morales commented on PHOENIX-4238: - Yes I can get it for you tomorrow. The code works just have to rewrite some of the tests to support multiple input splits. > MR IndexScrutinyTool break with salted tables and indexes on views > -- > > Key: PHOENIX-4238 > URL: https://issues.apache.org/jira/browse/PHOENIX-4238 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: churro morales > > The IndexScrutinyTool MR job doesn't work for salted and shared table. We > should add support for this, similar to PHOENIX-4233 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4138: Attachment: PHOENIX-4138.v2.patch [~jamestaylor] added an integration test and fixed the header. Hope this made it in time. > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Attachments: PHOENIX-4138.patch, PHOENIX-4138.v1.patch, > PHOENIX-4138.v2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4214) Scans which write should not block region split or close
[ https://issues.apache.org/jira/browse/PHOENIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179728#comment-16179728 ] churro morales commented on PHOENIX-4214: - +1 lgtm > Scans which write should not block region split or close > > > Key: PHOENIX-4214 > URL: https://issues.apache.org/jira/browse/PHOENIX-4214 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Attachments: PHOENIX-4214.master.v1.patch, > splitDuringUpsertSelect_wip.patch > > > PHOENIX-3111 introduced a scan reference counter which is checked during > region preSplit and preClose. However, a steady stream of UPSERT SELECT or > DELETE can keep the count above 0 indefinitely, preventing or greatly > delaying a region split or close. > We should try to avoid starvation of the split / close request, and > fail/reject queries where appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4138: Attachment: PHOENIX-4138.v1.patch added a unit test and dropped the default limit to 10. > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Attachments: PHOENIX-4138.patch, PHOENIX-4138.v1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159156#comment-16159156 ] churro morales commented on PHOENIX-4138: - I can extract a code block to unit test this, that would be much faster and it wouldn't add yet another integration test to slow down the suite. What do you think about that? > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Attachments: PHOENIX-4138.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-4138: Attachment: PHOENIX-4138.patch attached is the master patch, if you guys are good with this ill backport. > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Attachments: PHOENIX-4138.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157464#comment-16157464 ] churro morales commented on PHOENIX-4138: - Thanks [~jamestaylor] > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4138) Create a hard limit on number of indexes per table
[ https://issues.apache.org/jira/browse/PHOENIX-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157446#comment-16157446 ] churro morales commented on PHOENIX-4138: - what do you want to name this configuration parameter? Default of 20 is reasonable if not set? [~jamestaylor] [~rahul.srivast...@sun.com] > Create a hard limit on number of indexes per table > -- > > Key: PHOENIX-4138 > URL: https://issues.apache.org/jira/browse/PHOENIX-4138 > Project: Phoenix > Issue Type: Bug >Reporter: Rahul Shrivastava >Assignee: churro morales > Original Estimate: 48h > Remaining Estimate: 48h > > There should be a config parameter to impose a hard limit on number of > indexes per table. There is a SQL Exception > https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java#L260 > , but it gets triggered on the server side > (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L1589) > . > We need a client side limit that can be configured via Phoenix config > parameter. Something like if user create more than lets say 30 indexes per > table, it would not allow more index creation for the that specific table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983232#comment-15983232 ] churro morales commented on PHOENIX-3534: - that is fine, we resolve columns on read so they can be excluded quite easily. I believe we walk from child to parent always as well so we can just plug that logic into our getTable code. > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963590#comment-15963590 ] churro morales commented on PHOENIX-3534: - For the above approach, it seems like we will need to add (timestamp) to PColumn to get this information, otherwise we will end up doing lots of extra point gets and it looks like it wont be cached either. [~jamestaylor] what do you think? > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963585#comment-15963585 ] churro morales commented on PHOENIX-3534: - Discussed with [~jamestaylor] today. Right now we can only update per (table/view) so we know nothing about relations for add / drop columns or create view. So the logic can be the following: For all reads we do this: As we walk up the tree, we create a list of PColumns. If the column is contained in the parent as well, we see which one is older and keep that one (we take the min timestamp). For dropped columns as described above, we decide whether to drop the column based on the timestamp again but this time the decision is made based on the max timestamp. If the dropped column timestamp is newer than the columns timestamp, we exclude it, if it is older than the column timestamp we include it in the result. > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957964#comment-15957964 ] churro morales edited comment on PHOENIX-3534 at 4/5/17 10:58 PM: -- [~jamestaylor] how do you recommend we store this? Should we do it at the column level where we add a qualifier named "Excluded" or should we add it at the header row. But we would have to serialize all the columns and then once they are re-added to the table we would need to track them and remove them from our set. If we are storing this data structure in a single cell, is it possible this will get sufficiently large to cause issues? Problem with the column level approach is also we have to keep around those rows forever or we can only remove them when they have no child links I assume. was (Author: churromorales): [~jamestaylor] how do you recommend we store this? Should we do it at the column level where we add a qualifier named "Excluded" or should we add it at the header row. But we would have to serialize all the columns and then once they are re-added to the table we would need to track them and remove them from our set. If we are storing this data structure in a single cell, is it possible this will get sufficiently large to cause issues? > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957964#comment-15957964 ] churro morales commented on PHOENIX-3534: - [~jamestaylor] how do you recommend we store this? Should we do it at the column level where we add a qualifier named "Excluded" or should we add it at the header row. But we would have to serialize all the columns and then once they are re-added to the table we would need to track them and remove them from our set. If we are storing this data structure in a single cell, is it possible this will get sufficiently large to cause issues? > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937251#comment-15937251 ] churro morales commented on PHOENIX-3534: - [~tdsilva] [~jamestaylor] looks like the createTableInternal call from MetaDataClient passes the parent's columns, this is going to be an issue for upgrading. Looks like the document and what we discussed wont work as the client has logic for getting the parents columns for the createTable and the Server side does the logic for propagation of columns for add / delete columns. > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937235#comment-15937235 ] churro morales commented on PHOENIX-3534: - [~tdsilva] in MetaDataEndpointInpl.createTable() I can't see where the rows from the parent table are being propagated. I need to remove the logic of writing the parent's column(s) to this table. Are they passed in from the MetadataClient? > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-3534: --- Assignee: churro morales (was: Samarth Jain) > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: churro morales > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15935402#comment-15935402 ] churro morales commented on PHOENIX-3534: - Hey folks I thought I would add a doc to document this approach and what considerations we should be making. > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Samarth Jain > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15935402#comment-15935402 ] churro morales edited comment on PHOENIX-3534 at 3/21/17 9:54 PM: -- Hey folks I thought I would add a doc to document this approach and what considerations we should be making. https://docs.google.com/document/d/16p1FZReNHdQrvUj0NzLJ-Zx79J8-UE8Ku8bRPoql-Pc/edit?usp=sharing was (Author: churromorales): Hey folks I thought I would add a doc to document this approach and what considerations we should be making. > Support multi region SYSTEM.CATALOG table > - > > Key: PHOENIX-3534 > URL: https://issues.apache.org/jira/browse/PHOENIX-3534 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Samarth Jain > > Currently Phoenix requires that the SYSTEM.CATALOG table is single region > based on the server-side row locks being held for operations that impact a > table and all of it's views. For example, adding/removing a column from a > base table pushes this change to all views. > As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), > when a new table is created we can do a lazy cleanup of any rows that may be > left over from a failed DDL call (kudos to [~lhofhansl] for coming up with > this idea). To implement this efficiently, we'd need to also do PHOENIX-2051 > so that we can efficiently find derived views. > The implementation would rely on an optimistic concurrency model based on > checking our sequence numbers for each table/view before/after updating. Each > table/view row would be individually locked for their change (metadata for a > view or table cannot span regions due to our split policy), with the sequence > number being incremented under lock and then returned to the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (PHOENIX-2404) Create builder to construct PTableImpl
[ https://issues.apache.org/jira/browse/PHOENIX-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-2404: --- Assignee: churro morales > Create builder to construct PTableImpl > --- > > Key: PHOENIX-2404 > URL: https://issues.apache.org/jira/browse/PHOENIX-2404 > Project: Phoenix > Issue Type: Improvement >Reporter: Thomas D'Silva >Assignee: churro morales >Priority: Minor > Labels: newbie > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (PHOENIX-3711) Convert static methods which create PTables in PTableImpl to a Builder pattern
[ https://issues.apache.org/jira/browse/PHOENIX-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales resolved PHOENIX-3711. - Resolution: Duplicate > Convert static methods which create PTables in PTableImpl to a Builder pattern > -- > > Key: PHOENIX-3711 > URL: https://issues.apache.org/jira/browse/PHOENIX-3711 > Project: Phoenix > Issue Type: Task >Reporter: churro morales >Assignee: churro morales > > It will be nice to use a builder pattern such that we do not have to > constantly create static methods for one-off creations of our PTables. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (PHOENIX-3711) Convert static methods which create PTables in PTableImpl to a Builder pattern
churro morales created PHOENIX-3711: --- Summary: Convert static methods which create PTables in PTableImpl to a Builder pattern Key: PHOENIX-3711 URL: https://issues.apache.org/jira/browse/PHOENIX-3711 Project: Phoenix Issue Type: Task Reporter: churro morales Assignee: churro morales It will be nice to use a builder pattern such that we do not have to constantly create static methods for one-off creations of our PTables. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (PHOENIX-541) Make mutable batch size bytes-based instead of row-based
[ https://issues.apache.org/jira/browse/PHOENIX-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-541: --- Comment: was deleted (was: Is it possible to configure batches in terms of bytes and not row counts?) > Make mutable batch size bytes-based instead of row-based > > > Key: PHOENIX-541 > URL: https://issues.apache.org/jira/browse/PHOENIX-541 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 3.0-Release >Reporter: mujtaba > Labels: newbie > > With current configuration of row-count based mutable batch size, ideal value > for batch size is around 800 rather then current 15k when creating indexes > based on memory consumption, CPU and GC (data size: key: ~60 bytes, 14 > integer column in separate CFs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-541) Make mutable batch size bytes-based instead of row-based
[ https://issues.apache.org/jira/browse/PHOENIX-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703440#comment-15703440 ] churro morales commented on PHOENIX-541: Is it possible to do this in terms of bytes and not row counts? > Make mutable batch size bytes-based instead of row-based > > > Key: PHOENIX-541 > URL: https://issues.apache.org/jira/browse/PHOENIX-541 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 3.0-Release >Reporter: mujtaba > Labels: newbie > > With current configuration of row-count based mutable batch size, ideal value > for batch size is around 800 rather then current 15k when creating indexes > based on memory consumption, CPU and GC (data size: key: ~60 bytes, 14 > integer column in separate CFs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-541) Make mutable batch size bytes-based instead of row-based
[ https://issues.apache.org/jira/browse/PHOENIX-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703440#comment-15703440 ] churro morales edited comment on PHOENIX-541 at 11/28/16 11:08 PM: --- Is it possible to configure batches in terms of bytes and not row counts? was (Author: churromorales): Is it possible to do this in terms of bytes and not row counts? > Make mutable batch size bytes-based instead of row-based > > > Key: PHOENIX-541 > URL: https://issues.apache.org/jira/browse/PHOENIX-541 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 3.0-Release >Reporter: mujtaba > Labels: newbie > > With current configuration of row-count based mutable batch size, ideal value > for batch size is around 800 rather then current 15k when creating indexes > based on memory consumption, CPU and GC (data size: key: ~60 bytes, 14 > integer column in separate CFs) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2840) Fix flapping MemoryManagerTest.testWaitForMemoryAvailable unit test
[
https://issues.apache.org/jira/browse/PHOENIX-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15265154#comment-15265154
]
churro morales commented on PHOENIX-2840:
-
[~jamestaylor]let me take a look at why this test is still failing. I ran it
in isolation many times and it passed, even through the maven target as well.
I can revert it back but I believe everything was ignored before. Let me check
and get back to you.
> Fix flapping MemoryManagerTest.testWaitForMemoryAvailable unit test
> ---
>
> Key: PHOENIX-2840
> URL: https://issues.apache.org/jira/browse/PHOENIX-2840
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: churro morales
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2840.patch
>
>
> Looks like MemoryManagerTest.testWaitForMemoryAvailable is flapping.
> {code}
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.0/443/testReport/junit/org.apache.phoenix.memory/MemoryManagerTest/testWaitForMemoryAvailable/
> {code}
> I wonder if perhaps we should change reuseForks to false for our fast unit
> tests here in the pom.xml:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${maven-surefire-plugin.version}
>
> ${numForkedUT}
> true
> -enableassertions -Xmx2250m -XX:MaxPermSize=128m
> -Djava.security.egd=file:/dev/./urandom
> "-Djava.library.path=${hadoop.library.path}${path.separator}${java.library.path}"
>
> ${test.output.tofile}
> kill
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PHOENIX-2854) Fix MemoryManagerTest
[ https://issues.apache.org/jira/browse/PHOENIX-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-2854: --- Assignee: churro morales > Fix MemoryManagerTest > - > > Key: PHOENIX-2854 > URL: https://issues.apache.org/jira/browse/PHOENIX-2854 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: churro morales > > The test is still flaky and needs some love, for now it will be ignored and > this is a placeholder for me to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2854) Fix MemoryManagerTest
churro morales created PHOENIX-2854: --- Summary: Fix MemoryManagerTest Key: PHOENIX-2854 URL: https://issues.apache.org/jira/browse/PHOENIX-2854 Project: Phoenix Issue Type: Bug Reporter: churro morales The test is still flaky and needs some love, for now it will be ignored and this is a placeholder for me to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2839) support for hbase 1.2 codebase
[ https://issues.apache.org/jira/browse/PHOENIX-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2839: Attachment: PHOENIX-2839.patch This patch should only apply to master branch. After talking to [~jamestaylor] we decided to have master support hbase-1.2 as there were some API from 1.1 to 1.2 which we were relying on. > support for hbase 1.2 codebase > -- > > Key: PHOENIX-2839 > URL: https://issues.apache.org/jira/browse/PHOENIX-2839 > Project: Phoenix > Issue Type: Improvement >Reporter: Davide Gesino >Assignee: churro morales >Priority: Critical > Attachments: PHOENIX-2839.patch > > > It would be great if phoenix will support anytime in the future Hbase release > 1.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PHOENIX-2839) support for hbase 1.2 codebase
[ https://issues.apache.org/jira/browse/PHOENIX-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned PHOENIX-2839: --- Assignee: churro morales > support for hbase 1.2 codebase > -- > > Key: PHOENIX-2839 > URL: https://issues.apache.org/jira/browse/PHOENIX-2839 > Project: Phoenix > Issue Type: Improvement >Reporter: Davide Gesino >Assignee: churro morales >Priority: Critical > > It would be great if phoenix will support anytime in the future Hbase release > 1.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15238410#comment-15238410 ] churro morales commented on PHOENIX-2833: - unfortunately TableName is final > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[
https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237812#comment-15237812
]
churro morales commented on PHOENIX-2833:
-
Okay this might be a bigger discussion:
As stated in: https://hbase.apache.org/book.html#hbase.versioning
{quote} LimitedPrivate annotation comes with a set of target consumers for the
interfaces. Those consumers are coprocessors, phoenix, replication endpoint
implementations or similar. At this point, HBase only guarantees source and
binary compatibility for these interfaces between patch versions. {quote}
> Upgrade HBase dependency to version 1.2.0
> -
>
> Key: PHOENIX-2833
> URL: https://issues.apache.org/jira/browse/PHOENIX-2833
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 4.8.0
>Reporter: Rob Leidle
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: upgrade-to-hbase-1.2.0.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The
> Phoenix version is changed to reflect the HBase change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2822: Attachment: PHOENIX-2822.addendum-v1.patch [~samarth.j...@gmail.com] Put the tests that generate random tables in their own category and all tests now pass. Note this patch is based off 4.x-HBase-0.98 but should apply across all branches. > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.addendum, > PHOENIX-2822.addendum-v1.patch, PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237771#comment-15237771 ] churro morales commented on PHOENIX-2833: - [~jamestaylor] RpcScheduler.dispatch() API changed across versions unfortunately. In the PhoenixRpcScheduler we reference RpcExecutors directly which is bad because they are both @Private and @Evolving let me see if there is a way we can make this work. Maybe there is a way we can delegate instead of inherit, but I'm not sure yet. I'll look into this. > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2822: Attachment: PHOENIX-2822.addendum PhoenixRuntimeIT still breaks when run in a suite, didn't touch this test will have to figure out what state is being shared. PhoenixRuntimeIT.testGetTenantIdExpressionForUnsaltedTable:85->testGetTenantIdExpression:117->assertTenantIds:75 expected:<[, t1]> but was:<[, , t1]> > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.addendum, > PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reopened PHOENIX-2822: - some tests break due to shared state. > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2822: Attachment: PHOENIX-2822-98.patch patch for the 98 branch > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2822: Attachment: PHOENIX-2822.patch here is the rebased patch > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2810) Fixing IndexTool Dependencies
[ https://issues.apache.org/jira/browse/PHOENIX-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230388#comment-15230388 ] churro morales commented on PHOENIX-2810: - Its not the deprecation I am worried about. Its the fact that HFileOutputFormat is gone in 2.x version of HBase. LoadIncrementalFiles.doBulkLoad is available in branch 1 (all versions). https://github.com/apache/hbase/blob/rel/1.0.0/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java#L245 > Fixing IndexTool Dependencies > - > > Key: PHOENIX-2810 > URL: https://issues.apache.org/jira/browse/PHOENIX-2810 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2810.patch > > > IndexTool uses HFileOutputFormat which is deprecated. Use HFileOutputFormat2 > instead and fix other private dependencies for this class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
churro morales created PHOENIX-2822: --- Summary: Tests that extend BaseHBaseManagedTimeIT are very slow Key: PHOENIX-2822 URL: https://issues.apache.org/jira/browse/PHOENIX-2822 Project: Phoenix Issue Type: Improvement Affects Versions: 4.8.0 Reporter: churro morales Assignee: churro morales Since I am trying to refactor out all the hbase private dependencies, I have to constantly run tests to make sure I didn't break anything. The tests that extend BaseHBaseManagedTimeIT are very slow as they have to delete all non-system tables after every test case. This takes around 5-10 seconds to accomplish. This adds significant time to the test suite. I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates a random table name such that we dont have collisions for tests. It also doesn't do any cleanup after each test case or class because these table names should be unique. I moved about 30-35 tests out from BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2813) PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated classes and methods
[ https://issues.apache.org/jira/browse/PHOENIX-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222192#comment-15222192 ] churro morales commented on PHOENIX-2813: - This unfortunately will not be possible until https://issues.cask.co/browse/TEPHRA-173 TransactionAwareHTable is the problem that prevents us from doing the entire refactoring from HTableInterface to Table. > PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated > classes and methods > --- > > Key: PHOENIX-2813 > URL: https://issues.apache.org/jira/browse/PHOENIX-2813 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > > This mainly involves replacing all instances of HTableInterfaceReference with > Table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2813) PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated classes and methods
[ https://issues.apache.org/jira/browse/PHOENIX-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2813: Description: This mainly involves replacing all instances of HTableInterfaceReference with Table > PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated > classes and methods > --- > > Key: PHOENIX-2813 > URL: https://issues.apache.org/jira/browse/PHOENIX-2813 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Assignee: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > > This mainly involves replacing all instances of HTableInterfaceReference with > Table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2813) PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated classes and methods
churro morales created PHOENIX-2813: --- Summary: PhoenixIndexFailurePolicy and DelegateIndexFailurePolicy use deprecated classes and methods Key: PHOENIX-2813 URL: https://issues.apache.org/jira/browse/PHOENIX-2813 Project: Phoenix Issue Type: Bug Reporter: churro morales Assignee: churro morales Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2812) Fix UpgradeUtil HBase Dependencies
[ https://issues.apache.org/jira/browse/PHOENIX-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2812: Attachment: PHOENIX-2812.patch > Fix UpgradeUtil HBase Dependencies > -- > > Key: PHOENIX-2812 > URL: https://issues.apache.org/jira/browse/PHOENIX-2812 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2812.patch > > > UpgradeUtil relies on deprecated hbase classes which will break in the > future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2812) Fix UpgradeUtil HBase Dependencies
churro morales created PHOENIX-2812: --- Summary: Fix UpgradeUtil HBase Dependencies Key: PHOENIX-2812 URL: https://issues.apache.org/jira/browse/PHOENIX-2812 Project: Phoenix Issue Type: Bug Reporter: churro morales UpgradeUtil relies on deprecated hbase classes which will break in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2812) Fix UpgradeUtil HBase Dependencies
[ https://issues.apache.org/jira/browse/PHOENIX-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2812: Priority: Minor (was: Major) > Fix UpgradeUtil HBase Dependencies > -- > > Key: PHOENIX-2812 > URL: https://issues.apache.org/jira/browse/PHOENIX-2812 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > > UpgradeUtil relies on deprecated hbase classes which will break in the > future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2811) Fix HColumnDescriptor.setKeepDeletedCells(boolean)
[ https://issues.apache.org/jira/browse/PHOENIX-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2811: Attachment: PHOENIX-2811.patch > Fix HColumnDescriptor.setKeepDeletedCells(boolean) > -- > > Key: PHOENIX-2811 > URL: https://issues.apache.org/jira/browse/PHOENIX-2811 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2811.patch > > > This is deprecated and removed in later versions of hbase -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2811) Fix HColumnDescriptor.setKeepDeletedCells(boolean)
churro morales created PHOENIX-2811: --- Summary: Fix HColumnDescriptor.setKeepDeletedCells(boolean) Key: PHOENIX-2811 URL: https://issues.apache.org/jira/browse/PHOENIX-2811 Project: Phoenix Issue Type: Bug Reporter: churro morales Priority: Minor This is deprecated and removed in later versions of hbase -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2810) Fixing IndexTool Dependencies
[ https://issues.apache.org/jira/browse/PHOENIX-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2810: Attachment: PHOENIX-2810.patch > Fixing IndexTool Dependencies > - > > Key: PHOENIX-2810 > URL: https://issues.apache.org/jira/browse/PHOENIX-2810 > Project: Phoenix > Issue Type: Bug >Reporter: churro morales >Priority: Minor > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2810.patch > > > IndexTool uses HFileOutputFormat which is deprecated. Use HFileOutputFormat2 > instead and fix other private dependencies for this class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2810) Fixing IndexTool Dependencies
churro morales created PHOENIX-2810: --- Summary: Fixing IndexTool Dependencies Key: PHOENIX-2810 URL: https://issues.apache.org/jira/browse/PHOENIX-2810 Project: Phoenix Issue Type: Bug Reporter: churro morales Priority: Minor IndexTool uses HFileOutputFormat which is deprecated. Use HFileOutputFormat2 instead and fix other private dependencies for this class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2786) Can MultiTableOutputFormat be used instead of MultiHfileOutputFormat
[ https://issues.apache.org/jira/browse/PHOENIX-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15204501#comment-15204501 ] churro morales commented on PHOENIX-2786: - [~jamestaylor] Yes MultiTableOutputFormat is available in 0.98 and earlier versions as well. > Can MultiTableOutputFormat be used instead of MultiHfileOutputFormat > > > Key: PHOENIX-2786 > URL: https://issues.apache.org/jira/browse/PHOENIX-2786 > Project: Phoenix > Issue Type: Task >Reporter: churro morales > > MultiHfileOutputFormat depends on a lot of HBase classes that it shouldn't > depend on. It seems like MultiHfileOutputFormat and MultiTableOutputFormat > have the same goal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2786) Can MultiTableOutputFormat be used instead of MultiHfileOutputFormat
churro morales created PHOENIX-2786: --- Summary: Can MultiTableOutputFormat be used instead of MultiHfileOutputFormat Key: PHOENIX-2786 URL: https://issues.apache.org/jira/browse/PHOENIX-2786 Project: Phoenix Issue Type: Task Reporter: churro morales MultiHfileOutputFormat depends on a lot of HBase classes that it shouldn't depend on. It seems like MultiHfileOutputFormat and MultiTableOutputFormat have the same goal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2774) MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2774: Attachment: PHOENIX-2774-v1.patch changed the interface name as requested > MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner > > > Key: PHOENIX-2774 > URL: https://issues.apache.org/jira/browse/PHOENIX-2774 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Attachments: PHOENIX-2774-v1.patch, PHOENIX-2774.patch > > > Relates to PHOENIX-2756, trying to remove all dependencies on @Private > interfaces in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2774) MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15195872#comment-15195872 ] churro morales commented on PHOENIX-2774: - [~jamestaylor], [~tdsilva] Here is a patch getting rid of the KeyValueScanner dependencies in MemStoreScanner and KeyValueStore. Would like a review. > MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner > > > Key: PHOENIX-2774 > URL: https://issues.apache.org/jira/browse/PHOENIX-2774 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Attachments: PHOENIX-2774.patch > > > Relates to PHOENIX-2756, trying to remove all dependencies on @Private > interfaces in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2774) MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2774: Description: Relates to PHOENIX-2756, trying to remove all dependencies on @Private interfaces in HBase. (was: Relates to HBASE-14355, trying to remove all dependencies on @Private interfaces in HBase.) > MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner > > > Key: PHOENIX-2774 > URL: https://issues.apache.org/jira/browse/PHOENIX-2774 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Attachments: PHOENIX-2774.patch > > > Relates to PHOENIX-2756, trying to remove all dependencies on @Private > interfaces in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2774) MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2774: Attachment: PHOENIX-2774.patch Here is an attempt at getting rid of NonLazyKeyValueScanner dependencies. > MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner > > > Key: PHOENIX-2774 > URL: https://issues.apache.org/jira/browse/PHOENIX-2774 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Attachments: PHOENIX-2774.patch > > > Relates to HBASE-14355, trying to remove all dependencies on @Private > interfaces in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2774) MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner
churro morales created PHOENIX-2774: --- Summary: MemStoreScanner and KeyValueStore should not be aware of KeyValueScanner Key: PHOENIX-2774 URL: https://issues.apache.org/jira/browse/PHOENIX-2774 Project: Phoenix Issue Type: Task Affects Versions: 4.8.0 Reporter: churro morales Assignee: churro morales Relates to HBASE-14355, trying to remove all dependencies on @Private interfaces in HBase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191648#comment-15191648 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191645#comment-15191645 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191636#comment-15191636 ] churro morales commented on PHOENIX-2756: - Sure thing was thinking about that but didn't want to make a huge patch. I can create a new ticket and see what I can do about removing those dependencies. Thanks [~jamestaylor] > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Fix For: 4.8.0 > > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191522#comment-15191522 ] churro morales edited comment on PHOENIX-2756 at 3/11/16 9:38 PM: -- [~jamestaylor] ran tests, all passed locally was (Author: churromorales): ~jamestaylor ran tests, all passed locally > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191522#comment-15191522 ] churro morales commented on PHOENIX-2756: - ~jamestaylor ran tests, all passed locally > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190476#comment-15190476 ] churro morales commented on PHOENIX-2756: - [~jamestaylor] I ran tests for the phoenix-core module (all passed) but will run all tests tomorrow morning and let you know the results. > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2756: Attachment: PHOENIX-2756.patch [~tdsilva] wanted to ask you for a review. Related to this feature HBASE-15130. We reverted and kept the API the same for HBase-98 but the API for KeyValueScanner changes in 1.2+ . I think this patch should work as no other projects depend on FilteredKeyValueScanner directly. > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > Attachments: PHOENIX-2756.patch > > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2756) FilteredKeyValueScanner should not implement KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2756: Summary: FilteredKeyValueScanner should not implement KeyValueScanner (was: Remove dependency on KeyValueScanner) > FilteredKeyValueScanner should not implement KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2756) Remove dependency on KeyValueScanner
[ https://issues.apache.org/jira/browse/PHOENIX-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2756: Description: In HBASE-14355, the API for KeyValueScanner changed. More specifically the method shouldUseScanner() had a signature change. Phoenix has a class: FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I will put up a patch that doesn't change the API signature ( a little hacky) but this signature change is already in HBase-1.2+. Either we can raise the scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its @Private so people don't assume that external services are depending on the API. I'll look into how we can make things work in Phoenix land. (was: In HBASE-14355, the API for KeyValueScanner changed. More specifically the method shouldUseScanner() had a signature change. For HBase 98, I will put up a patch that doesn't change the API signature ( a little hacky) but this signature change is already in HBase-1.2+. Either we can raise the scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its @Private so people don't assume that external services are depending on the API. I'll look into how we can make things work in Phoenix land.) > Remove dependency on KeyValueScanner > > > Key: PHOENIX-2756 > URL: https://issues.apache.org/jira/browse/PHOENIX-2756 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: churro morales > > In HBASE-14355, the API for KeyValueScanner changed. More specifically the > method shouldUseScanner() had a signature change. Phoenix has a class: > FilteredKeyValueScanner which implements KeyValueScanner. For HBase 98, I > will put up a patch that doesn't change the API signature ( a little hacky) > but this signature change is already in HBase-1.2+. Either we can raise the > scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its > @Private so people don't assume that external services are depending on the > API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2756) Remove dependency on KeyValueScanner
churro morales created PHOENIX-2756: --- Summary: Remove dependency on KeyValueScanner Key: PHOENIX-2756 URL: https://issues.apache.org/jira/browse/PHOENIX-2756 Project: Phoenix Issue Type: Task Affects Versions: 4.8.0 Reporter: churro morales In HBASE-14355, the API for KeyValueScanner changed. More specifically the method shouldUseScanner() had a signature change. For HBase 98, I will put up a patch that doesn't change the API signature ( a little hacky) but this signature change is already in HBase-1.2+. Either we can raise the scope of KeyValueScanner to @LimitedPrivate in HBase land. Right now its @Private so people don't assume that external services are depending on the API. I'll look into how we can make things work in Phoenix land. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
