[jira] [Updated] (PHOENIX-5156) Consistent Mutable Global Indexes for Non-Transactional Tables
[ https://issues.apache.org/jira/browse/PHOENIX-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5156: --- Attachment: PHOENIX-5156.master.005.patch > Consistent Mutable Global Indexes for Non-Transactional Tables > -- > > Key: PHOENIX-5156 > URL: https://issues.apache.org/jira/browse/PHOENIX-5156 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0, 4.14.0, 5.0.0, 4.14.1 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Attachments: PHOENIX-5156.master.001.patch, > PHOENIX-5156.master.002.patch, PHOENIX-5156.master.003.patch, > PHOENIX-5156.master.004.patch, PHOENIX-5156.master.005.patch > > Time Spent: 5h 40m > Remaining Estimate: 0h > > Without transactional tables, the mutable global indexes can get easily out > of sync with their data tables in Phoenix. Transactional tables require a > separate transaction manager, have some restrictions and performance > penalties. This issue is to have consistent mutable global indexes without > the need for using transactional tables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5219) Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
[
https://issues.apache.org/jira/browse/PHOENIX-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated PHOENIX-5219:
Description:
These tests are failing because when we set the timestamp in
{{Indexer.preBatchMutateWithExceptions}} we call
{{KeyValueUtil.ensureKeyValues}} on the list of cells and then call
{{KeyValue.getTimestampOffset}}
Pre 2.0 the cells objects are NoTagsKeyValue (which extend KeyValue). In 2.0
they are NoTagsByteBufferKeyValue (which doesn't extend KeyValue) so
{{KeyValueUtil.ensureKeyValues}} returns a new list of objects on which we set
the timestamp.
The fix us to use {{CellUtil.setTimestamp}} to the set the timestamp directly
on the cell.
was:
These tests are failing because when we set the timestamp in
{{Indexer.preBatchMutateWithExceptions}} we call
{{KeyValueUtil.ensureKeyValues}} on the list of cells and then call
{{KeyValue.getTimestampOffset}}
Pre 2.0 the cells objects are NoTagsKeyValue (which extend KeyValue). In 2.0
they are NoTagsByteBufferKeyValue (which doesn't extend KeyValue) so
{{KeyValueUtil.ensureKeyValues}} returns a new list of objects on which we set
the timestamp.
The fix us to use a method in CellUtil that allows you to the set the timestamp
directly on the cell
> Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and
> testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
>
>
> Key: PHOENIX-5219
> URL: https://issues.apache.org/jira/browse/PHOENIX-5219
> Project: Phoenix
> Issue Type: Test
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: PHOENIX-5219.patch
>
>
> These tests are failing because when we set the timestamp in
> {{Indexer.preBatchMutateWithExceptions}} we call
> {{KeyValueUtil.ensureKeyValues}} on the list of cells and then call
> {{KeyValue.getTimestampOffset}}
> Pre 2.0 the cells objects are NoTagsKeyValue (which extend KeyValue). In 2.0
> they are NoTagsByteBufferKeyValue (which doesn't extend KeyValue) so
> {{KeyValueUtil.ensureKeyValues}} returns a new list of objects on which we
> set the timestamp.
> The fix us to use {{CellUtil.setTimestamp}} to the set the timestamp
> directly on the cell.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5219) Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
[
https://issues.apache.org/jira/browse/PHOENIX-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated PHOENIX-5219:
Description:
These tests are failing because when we set the timestamp in
{{Indexer.preBatchMutateWithExceptions}} we call
{{KeyValueUtil.ensureKeyValues}} on the list of cells and then call
{{KeyValue.getTimestampOffset}}
Pre 2.0 the cells objects are NoTagsKeyValue (which extend KeyValue). In 2.0
they are NoTagsByteBufferKeyValue (which doesn't extend KeyValue) so
{{KeyValueUtil.ensureKeyValues}} returns a new list of objects on which we set
the timestamp.
The fix us to use a method in CellUtil that allows you to the set the timestamp
directly on the cell
> Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and
> testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
>
>
> Key: PHOENIX-5219
> URL: https://issues.apache.org/jira/browse/PHOENIX-5219
> Project: Phoenix
> Issue Type: Test
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: PHOENIX-5219.patch
>
>
> These tests are failing because when we set the timestamp in
> {{Indexer.preBatchMutateWithExceptions}} we call
> {{KeyValueUtil.ensureKeyValues}} on the list of cells and then call
> {{KeyValue.getTimestampOffset}}
> Pre 2.0 the cells objects are NoTagsKeyValue (which extend KeyValue). In 2.0
> they are NoTagsByteBufferKeyValue (which doesn't extend KeyValue) so
> {{KeyValueUtil.ensureKeyValues}} returns a new list of objects on which we
> set the timestamp.
> The fix us to use a method in CellUtil that allows you to the set the
> timestamp directly on the cell
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5219) Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
[ https://issues.apache.org/jira/browse/PHOENIX-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-5219: Attachment: PHOENIX-5219.patch > Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and > testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch > > > Key: PHOENIX-5219 > URL: https://issues.apache.org/jira/browse/PHOENIX-5219 > Project: Phoenix > Issue Type: Test >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva >Priority: Major > Fix For: 5.1.0 > > Attachments: PHOENIX-5219.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-5219) Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch
Thomas D'Silva created PHOENIX-5219: --- Summary: Fix ConcurrentMutationsIT testLockUntilMVCCAdvanced and testRowLockDuringPreBatchMutateWhenIndexed failures on the master branch Key: PHOENIX-5219 URL: https://issues.apache.org/jira/browse/PHOENIX-5219 Project: Phoenix Issue Type: Test Reporter: Thomas D'Silva Assignee: Thomas D'Silva Fix For: 5.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5218) When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still transition Index from INACTIVE to ACTIVE
[ https://issues.apache.org/jira/browse/PHOENIX-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated PHOENIX-5218: -- Description: With PHOENIX-5094, we were handling index transition from INACTIVE to ACTIVE state While debugging test cases failures for PHOENIX-5194 for PartialIndexRebuilderIT, two test cases 1) testIndexWriteFailureDisablingIndex 2) testIndexWriteFailureLeavingIndexActive fails. For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in above mentioned test cases round robin Partial Index rebuilder is being used instead of building entire index from INDEX_DISABLE_TIMESTAMP. was: While debugging test cases failures for PHOENIX-5194 for PartialIndexRebuilderIT, two test cases 1) testIndexWriteFailureDisablingIndex 2) testIndexWriteFailureLeavingIndexActive fails. For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in above mentioned test cases round robin Partial Index rebuilder is being used instead of building entire index from INDEX_DISABLE_TIMESTAMP. > When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still > transition Index from INACTIVE to ACTIVE > > > Key: PHOENIX-5218 > URL: https://issues.apache.org/jira/browse/PHOENIX-5218 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.15.0, 4.14.1, 5.1.0 >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Critical > Attachments: PHOENIX-5218-4.x-HBase-1.3.01.patch > > > With PHOENIX-5094, we were handling index transition from INACTIVE to ACTIVE > state > While debugging test cases failures for PHOENIX-5194 for > PartialIndexRebuilderIT, two test cases 1) > testIndexWriteFailureDisablingIndex 2) > testIndexWriteFailureLeavingIndexActive fails. > For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in > above mentioned test cases round robin Partial Index rebuilder is being used > instead of building entire index from INDEX_DISABLE_TIMESTAMP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5218) When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still transition Index from INACTIVE to ACTIVE
[ https://issues.apache.org/jira/browse/PHOENIX-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated PHOENIX-5218: -- Issue Type: Bug (was: Sub-task) Parent: (was: PHOENIX-5094) > When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still > transition Index from INACTIVE to ACTIVE > > > Key: PHOENIX-5218 > URL: https://issues.apache.org/jira/browse/PHOENIX-5218 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.15.0, 4.14.1, 5.1.0 >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Critical > Attachments: PHOENIX-5218-4.x-HBase-1.3.01.patch > > > While debugging test cases failures for PHOENIX-5194 for > PartialIndexRebuilderIT, two test cases 1) > testIndexWriteFailureDisablingIndex 2) > testIndexWriteFailureLeavingIndexActive fails. > For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in > above mentioned test cases round robin Partial Index rebuilder is being used > instead of building entire index from INDEX_DISABLE_TIMESTAMP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5218) When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still transition Index from INACTIVE to ACTIVE
[ https://issues.apache.org/jira/browse/PHOENIX-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated PHOENIX-5218: -- Attachment: PHOENIX-5218-4.x-HBase-1.3.01.patch > When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still > transition Index from INACTIVE to ACTIVE > > > Key: PHOENIX-5218 > URL: https://issues.apache.org/jira/browse/PHOENIX-5218 > Project: Phoenix > Issue Type: Sub-task >Affects Versions: 4.15.0, 4.14.1, 5.1.0 >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Critical > Attachments: PHOENIX-5218-4.x-HBase-1.3.01.patch > > > While debugging test cases failures for PHOENIX-5194 for > PartialIndexRebuilderIT, two test cases 1) > testIndexWriteFailureDisablingIndex 2) > testIndexWriteFailureLeavingIndexActive fails. > For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in > above mentioned test cases round robin Partial Index rebuilder is being used > instead of building entire index from INDEX_DISABLE_TIMESTAMP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-5218) When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still transition Index from INACTIVE to ACTIVE
Monani Mihir created PHOENIX-5218: - Summary: When INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set, Phoenix Client can still transition Index from INACTIVE to ACTIVE Key: PHOENIX-5218 URL: https://issues.apache.org/jira/browse/PHOENIX-5218 Project: Phoenix Issue Type: Sub-task Affects Versions: 4.14.1, 4.15.0, 5.1.0 Reporter: Monani Mihir Assignee: Monani Mihir While debugging test cases failures for PHOENIX-5194 for PartialIndexRebuilderIT, two test cases 1) testIndexWriteFailureDisablingIndex 2) testIndexWriteFailureLeavingIndexActive fails. For this IT, INDEX_FAILURE_HANDLING_REBUILD_PERIOD is set to 50sec and in above mentioned test cases round robin Partial Index rebuilder is being used instead of building entire index from INDEX_DISABLE_TIMESTAMP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5217) Incorrect result for COUNT DISTINCT ... limit ...
[
https://issues.apache.org/jira/browse/PHOENIX-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Feng updated PHOENIX-5217:
---
Description:
For table t1(pk1, col1, CONSTRAINT(pk1))
upsert into "t1" values (1, 1);
upsert into "t1" values (2, 2);
sql A: select count("pk1") from "t1" limit 1, return 2 [correct]
sql B: select count(disctinct("pk1")) from "t1" limit 1, return 1 [incorrect]
was:
For table t1(pk1, col1, CONSTRAINT(pk1))
upsert into "t1" values (1, 1);
upsert into "t1" values (2, 2);
sql1: select count("pk1") from "t1" limit 1, return 2 [correct]
sql2: select count(disctinct("pk1")) from "t1" limit 1, return 1 [incorrect]
> Incorrect result for COUNT DISTINCT ... limit ...
> -
>
> Key: PHOENIX-5217
> URL: https://issues.apache.org/jira/browse/PHOENIX-5217
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
> Environment: 4.14.1: incorrect
> 4.6: correct.
>
>Reporter: Chen Feng
>Priority: Critical
>
> For table t1(pk1, col1, CONSTRAINT(pk1))
> upsert into "t1" values (1, 1);
> upsert into "t1" values (2, 2);
> sql A: select count("pk1") from "t1" limit 1, return 2 [correct]
> sql B: select count(disctinct("pk1")) from "t1" limit 1, return 1 [incorrect]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5217) Incorrect result for COUNT DISTINCT ... limit ...
[
https://issues.apache.org/jira/browse/PHOENIX-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Feng updated PHOENIX-5217:
---
Environment:
4.14.1: incorrect
4.6: correct.
was:
Phoenix 4.14.1 returns the incorrect answer.
Phoenix 4.6 is correct.
No other version is tested.
> Incorrect result for COUNT DISTINCT ... limit ...
> -
>
> Key: PHOENIX-5217
> URL: https://issues.apache.org/jira/browse/PHOENIX-5217
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
> Environment: 4.14.1: incorrect
> 4.6: correct.
>
>Reporter: Chen Feng
>Priority: Critical
>
> For table t1(pk1, col1, CONSTRAINT(pk1))
> upsert into "t1" values (1, 1);
> upsert into "t1" values (2, 2);
> sql1: select count("pk1") from "t1" limit 1, return 2 [correct]
> sql2: select count(disctinct("pk1")) from "t1" limit 1, return 1 [incorrect]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-5217) Incorrect result for COUNT DISTINCT ... limit ...
Chen Feng created PHOENIX-5217:
--
Summary: Incorrect result for COUNT DISTINCT ... limit ...
Key: PHOENIX-5217
URL: https://issues.apache.org/jira/browse/PHOENIX-5217
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.14.1
Environment: Phoenix 4.14.1 returns the incorrect answer.
Phoenix 4.6 is correct.
No other version is tested.
Reporter: Chen Feng
For table t1(pk1, col1, CONSTRAINT(pk1))
upsert into "t1" values (1, 1);
upsert into "t1" values (2, 2);
sql1: select count("pk1") from "t1" limit 1, return 2 [correct]
sql2: select count(disctinct("pk1")) from "t1" limit 1, return 1 [incorrect]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
