[jira] [Updated] (PHOENIX-5020) PhoenixMRJobSubmitter should use a long timeout when getting candidate jobs
[ https://issues.apache.org/jira/browse/PHOENIX-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby updated PHOENIX-5020: - Priority: Minor (was: Blocker) > PhoenixMRJobSubmitter should use a long timeout when getting candidate jobs > --- > > Key: PHOENIX-5020 > URL: https://issues.apache.org/jira/browse/PHOENIX-5020 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.14.1 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Minor > Labels: SFDC > Fix For: 5.1.0, 4.15.1 > > > If an environment has a huge System.Catalog (such as having many views) the > query in getCandidateJobs can timeout. Because of PHOENIX-4936, this looks > like there are no indexes that need an async rebuild. In addition to fixing > PHOENIX-4936, we should extend the timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Test failures with some version of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Summary: Test failures with some version of HBase. (was: HBase 1.5
specific test failures)
> Test failures with some version of HBase.
> -
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Priority: Critical
> Fix For: 4.15.0
>
> Attachments: 5303.txt
>
>
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Summary: Fix index failures with some versions of HBase. (was: Test
failures with some version of HBase.)
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Priority: Critical
> Fix For: 4.15.0
>
> Attachments: 5303.txt
>
>
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Fix Version/s: 5.1.0
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Priority: Critical
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Priority: Blocker (was: Critical)
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Lars Hofhansl
>Priority: Blocker
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Description:
The problem was introduced with HBASE-21158. The fix here works regardless of
the HBase version.
This must have started very recently, but it's already past the history of the
test runs.
Or perhaps it never works in 4.x-HBase-1.5
[~apurtell], in case you have any ideas.
{code:java}
[INFO] Running
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403 s
<<< FAILURE! - in
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
[ERROR]
testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
Time elapsed: 0.16 s <<< FAILURE!
java.lang.AssertionError: Had some index updates, though it should have been
covered by the delete
at
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
at
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
{code}
MutableIndexIT fails as well (for non-transactional indexes)
was:
This must have started very recently, but it's already past the history of the
test runs.
Or perhaps it never works in 4.x-HBase-1.5
[~apurtell], in case you have any ideas.
{code:java}
[INFO] Running
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403 s
<<< FAILURE! - in
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
[ERROR]
testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
Time elapsed: 0.16 s <<< FAILURE!
java.lang.AssertionError: Had some index updates, though it should have been
covered by the delete
at
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
at
org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
{code}
MutableIndexIT fails as well (for non-transactional indexes)
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Priority: Critical
> Fix For: 4.15.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5303:
---
Affects Version/s: 5.1.0
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Lars Hofhansl
>Priority: Critical
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl reassigned PHOENIX-5303:
--
Assignee: Lars Hofhansl
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Blocker
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (PHOENIX-5303) Fix index failures with some versions of HBase.
[
https://issues.apache.org/jira/browse/PHOENIX-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved PHOENIX-5303.
Resolution: Fixed
> Fix index failures with some versions of HBase.
> ---
>
> Key: PHOENIX-5303
> URL: https://issues.apache.org/jira/browse/PHOENIX-5303
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0, 5.1.0
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Blocker
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5303.txt
>
>
> The problem was introduced with HBASE-21158. The fix here works regardless of
> the HBase version.
> This must have started very recently, but it's already past the history of
> the test runs.
> Or perhaps it never works in 4.x-HBase-1.5
> [~apurtell], in case you have any ideas.
> {code:java}
> [INFO] Running
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.403
> s <<< FAILURE! - in
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec
> [ERROR]
> testGeneratedIndexUpdates(org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec)
> Time elapsed: 0.16 s <<< FAILURE!
> java.lang.AssertionError: Had some index updates, though it should have been
> covered by the delete
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.ensureNoUpdatesWhenCoveredByDelete(TestCoveredColumnIndexCodec.java:242)
> at
> org.apache.phoenix.hbase.index.covered.TestCoveredColumnIndexCodec.testGeneratedIndexUpdates(TestCoveredColumnIndexCodec.java:220)
> {code}
>
> MutableIndexIT fails as well (for non-transactional indexes)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5304) LocalIndexSplitMergeIT fails with HBase 1.5.x
[
https://issues.apache.org/jira/browse/PHOENIX-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5304:
---
Priority: Blocker (was: Major)
> LocalIndexSplitMergeIT fails with HBase 1.5.x
> -
>
> Key: PHOENIX-5304
> URL: https://issues.apache.org/jira/browse/PHOENIX-5304
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Blocker
> Fix For: 4.15.0
>
> Attachments: 5304-v2.txt, 5304.txt
>
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Timestamp cannot be negative,
> ts=-9223372036854775808,
> KeyValueBytesHex=\x00\x00\x001\x00\x00\x00\x00\x00%\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00w\x00\x00\x80\x00\x00\x02\x80\x00\x00\x03\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00,
> offset=0, length=57
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:659)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:359)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:348)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.getKeyPresentInHFiles(LocalIndexStoreFileScanner.java:198)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.seekOrReseek(LocalIndexStoreFileScanner.java:233)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.reseek(LocalIndexStoreFileScanner.java:112)
> at
> org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:54)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:316)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.requestSeek(KeyValueHeap.java:269)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:1038)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekToNextRow(StoreScanner.java:1016)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekOrSkipToNextRow(StoreScanner.java:738)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:624)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:152)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:6292)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:6452)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6224)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6210)
> at
> org.apache.phoenix.iterate.RegionScannerFactory$1.nextRaw(RegionScannerFactory.java:172)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5129) Evaluate using same cell as the data cell for storing dynamic column metadata
[ https://issues.apache.org/jira/browse/PHOENIX-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5129: -- Priority: Major (was: Blocker) > Evaluate using same cell as the data cell for storing dynamic column metadata > - > > Key: PHOENIX-5129 > URL: https://issues.apache.org/jira/browse/PHOENIX-5129 > Project: Phoenix > Issue Type: Improvement >Reporter: Chinmay Kulkarni >Assignee: Chinmay Kulkarni >Priority: Major > Fix For: 4.15.0, 5.1.0 > > > In PHOENIX-374 we use shadow cells to store metadata for dynamic columns in > order to be able to project these columns for wildcard queries. More details > outlined in the [design > doc|https://docs.google.com/document/d/1-N6Z6Id0LzJ457BHT542cxqdKfeZgkFvKGW4xKDPtqs/edit]. > This Jira is to discuss changing the approach so that we can store the > metadata in the same cell as the dynamic column data, instead of separate > shadow cells. This will help reduce the size of store files since we don't > have to store additional rows corresponding to the shadow cell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-5304) LocalIndexSplitMergeIT fails with HBase 1.5.x
[
https://issues.apache.org/jira/browse/PHOENIX-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved PHOENIX-5304.
Resolution: Fixed
Pushed to 4x-HBase-1.5
> LocalIndexSplitMergeIT fails with HBase 1.5.x
> -
>
> Key: PHOENIX-5304
> URL: https://issues.apache.org/jira/browse/PHOENIX-5304
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Blocker
> Fix For: 4.15.0
>
> Attachments: 5304-v2.txt, 5304.txt
>
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Timestamp cannot be negative,
> ts=-9223372036854775808,
> KeyValueBytesHex=\x00\x00\x001\x00\x00\x00\x00\x00%\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00w\x00\x00\x80\x00\x00\x02\x80\x00\x00\x03\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00,
> offset=0, length=57
> at
> org.apache.hadoop.hbase.KeyValueUtil.checkKeyValueBytes(KeyValueUtil.java:659)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:359)
> at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:348)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.getKeyPresentInHFiles(LocalIndexStoreFileScanner.java:198)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.seekOrReseek(LocalIndexStoreFileScanner.java:233)
> at
> org.apache.hadoop.hbase.regionserver.LocalIndexStoreFileScanner.reseek(LocalIndexStoreFileScanner.java:112)
> at
> org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:54)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:316)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.requestSeek(KeyValueHeap.java:269)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:1038)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekToNextRow(StoreScanner.java:1016)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekOrSkipToNextRow(StoreScanner.java:738)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:624)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:152)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:6292)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:6452)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6224)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6210)
> at
> org.apache.phoenix.iterate.RegionScannerFactory$1.nextRaw(RegionScannerFactory.java:172)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5057) LocalIndexSplitMergeIT and MutableIndexIT are failing in cdh branches
[
https://issues.apache.org/jira/browse/PHOENIX-5057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-5057:
---
Fix Version/s: (was: 4.15.0)
> LocalIndexSplitMergeIT and MutableIndexIT are failing in cdh branches
> -
>
> Key: PHOENIX-5057
> URL: https://issues.apache.org/jira/browse/PHOENIX-5057
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0, 4.14.1
>Reporter: Pedro Boado
>Assignee: Rajeshbabu Chintaguntla
>Priority: Blocker
> Labels: cdh
> Attachments: PHOENIX-5057.patch
>
>
> LocalIndexSplitMergeIT started failing in CDH branches after PHOENIX-4839.
> For some reason it looks like LocalIndexes are not splitting when the table
> is splitted. HBase-1.2 branch seems to be OK.
> {code}
> 2018-12-03 21:02:03,007 DEBUG [phoenix-2-thread-3]
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas(205): Scan with
> primary region returns org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: ERROR 1108 (XCL08): Cache of
> region boundaries are out of date. tableName=T01.T02
> at
> org.apache.phoenix.coprocessor.BaseScannerRegionObserver.throwIfScanOutOfRegion(BaseScannerRegionObserver.java:175)
> at
> org.apache.phoenix.coprocessor.BaseScannerRegionObserver.preScannerOpen(BaseScannerRegionObserver.java:203)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$50.call(RegionCoprocessorHost.java:1300)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1749)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperationWithResult(RegionCoprocessorHost.java:1722)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preScannerOpen(RegionCoprocessorHost.java:1295)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:2406)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:33648)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2191)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:183)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:163)
> Caused by: org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR
> 1108 (XCL08): Cache of region boundaries are out of date.
> tableName=T01.T02
> at
> org.apache.phoenix.coprocessor.BaseScannerRegionObserver.throwIfScanOutOfRegion(BaseScannerRegionObserver.java:174)
> ... 12 more
> {code}
> MutableIndexIT to be investigated, it also seems to be related to local index
> implementation after same PHOENIX-4839.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5129) Evaluate using same cell as the data cell for storing dynamic column metadata
[ https://issues.apache.org/jira/browse/PHOENIX-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-5129: --- Fix Version/s: (was: 4.15.0) 4.15.1 > Evaluate using same cell as the data cell for storing dynamic column metadata > - > > Key: PHOENIX-5129 > URL: https://issues.apache.org/jira/browse/PHOENIX-5129 > Project: Phoenix > Issue Type: Improvement >Reporter: Chinmay Kulkarni >Assignee: Chinmay Kulkarni >Priority: Major > Fix For: 5.1.0, 4.15.1 > > > In PHOENIX-374 we use shadow cells to store metadata for dynamic columns in > order to be able to project these columns for wildcard queries. More details > outlined in the [design > doc|https://docs.google.com/document/d/1-N6Z6Id0LzJ457BHT542cxqdKfeZgkFvKGW4xKDPtqs/edit]. > This Jira is to discuss changing the approach so that we can store the > metadata in the same cell as the dynamic column data, instead of separate > shadow cells. This will help reduce the size of store files since we don't > have to store additional rows corresponding to the shadow cell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-2544) Update phoenix-spark PhoenixRecordWritable to use phoenix-core implementation
[ https://issues.apache.org/jira/browse/PHOENIX-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-2544: --- Fix Version/s: (was: 4.15.0) > Update phoenix-spark PhoenixRecordWritable to use phoenix-core implementation > - > > Key: PHOENIX-2544 > URL: https://issues.apache.org/jira/browse/PHOENIX-2544 > Project: Phoenix > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Thomas D'Silva >Priority: Major > > There's a number of implementations of PhoenixRecordWritable strewn about. We > should consolidate them and reuse code. See discussion on PHOENIX-2492. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4850) Like predicate without wildcard doesn't pass the exact string if varchar columns has maxlength
[
https://issues.apache.org/jira/browse/PHOENIX-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal updated PHOENIX-4850:
---
Fix Version/s: (was: 4.15.0)
> Like predicate without wildcard doesn't pass the exact string if varchar
> columns has maxlength
> ---
>
> Key: PHOENIX-4850
> URL: https://issues.apache.org/jira/browse/PHOENIX-4850
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Ankit Singhal
>Priority: Major
>
> [William
> |https://community.hortonworks.com/users/11882/williamprendergast.html]reported
> on
> [https://community.hortonworks.com/questions/210582/like-query-in-phoenix.html]
> that query is skipping all rows when length of the literal doesn't match
> with max lenght of the varchar column.
> Copied from above link:-
> When using a LIKE in a where clause, the rows are not found unless a
> wildcard(%) is added
> create table t ( ID VARCHAR(290) NOT NULL PRIMARY KEY, NAME VARCHAR(256));
> No rows affected (1.386 seconds) 0:
> jdbc:phoenix:> upsert into t values ('1','test');
> 1 row affected (0.046 seconds) 0:
> jdbc:phoenix:> select * from t;
> +-+---+
> | ID | NAME |
> +-+---+
> | 1 | test |
> +-+---+
> 1 row selected (0.05 seconds) 0:
> jdbc:phoenix:> select * from t where name like 'test';
> +-+---+
> | ID | NAME |
> +-+---+
> +-+---+
> No rows selected (0.016 seconds) 0:
> jdbc:phoenix:> select * from t where name like 'test%';
> +-+---+
> | ID | NAME |
> +-+---+
> | 1 | test |
> +-+---+
> 1 row selected (0.032 seconds)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4850) Like predicate without wildcard doesn't pass the exact string if varchar columns has maxlength
[
https://issues.apache.org/jira/browse/PHOENIX-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal reassigned PHOENIX-4850:
--
Assignee: (was: Ankit Singhal)
> Like predicate without wildcard doesn't pass the exact string if varchar
> columns has maxlength
> ---
>
> Key: PHOENIX-4850
> URL: https://issues.apache.org/jira/browse/PHOENIX-4850
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Ankit Singhal
>Priority: Major
> Fix For: 4.15.0
>
>
> [William
> |https://community.hortonworks.com/users/11882/williamprendergast.html]reported
> on
> [https://community.hortonworks.com/questions/210582/like-query-in-phoenix.html]
> that query is skipping all rows when length of the literal doesn't match
> with max lenght of the varchar column.
> Copied from above link:-
> When using a LIKE in a where clause, the rows are not found unless a
> wildcard(%) is added
> create table t ( ID VARCHAR(290) NOT NULL PRIMARY KEY, NAME VARCHAR(256));
> No rows affected (1.386 seconds) 0:
> jdbc:phoenix:> upsert into t values ('1','test');
> 1 row affected (0.046 seconds) 0:
> jdbc:phoenix:> select * from t;
> +-+---+
> | ID | NAME |
> +-+---+
> | 1 | test |
> +-+---+
> 1 row selected (0.05 seconds) 0:
> jdbc:phoenix:> select * from t where name like 'test';
> +-+---+
> | ID | NAME |
> +-+---+
> +-+---+
> No rows selected (0.016 seconds) 0:
> jdbc:phoenix:> select * from t where name like 'test%';
> +-+---+
> | ID | NAME |
> +-+---+
> | 1 | test |
> +-+---+
> 1 row selected (0.032 seconds)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4863) Setup Travis CI to automatically run all the integration tests when a PR is created on github.com/apache/phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Priyank Porwal reassigned PHOENIX-4863: --- Assignee: Priyank Porwal > Setup Travis CI to automatically run all the integration tests when a PR is > created on github.com/apache/phoenix > > > Key: PHOENIX-4863 > URL: https://issues.apache.org/jira/browse/PHOENIX-4863 > Project: Phoenix > Issue Type: Test >Reporter: Thomas D'Silva >Assignee: Priyank Porwal >Priority: Major > > Apache Tephra does this (see > https://travis-ci.org/apache/incubator-tephra/jobs/278449357) > If would be convenient if the tests are run automatically when a PR is > created instead of the contributor having to manually create a patch file, > attach it on the JIRA and click the submit button. > See https://docs.travis-ci.com/user/getting-started -- This message was sent by Atlassian JIRA (v7.6.3#76005)
PHOENIX-4863: Setup Travis-CI & CodeCoverage
Hi, What do you guys think about this work to setup Travis-CI and CodeCoverage for Phoenix? The objective would be to run unit and integration tests on each PR, show code-coverage reports and perhaps also do checkstyle checks (after initial scrubbing effort). This would help rid of manual patch uploads that we need currently, plus bring visibility into code health. Thoughts? https://issues.apache.org/jira/browse/PHOENIX-4863 Thanks, Priyank
Re: PHOENIX-4863: Setup Travis-CI & CodeCoverage
+1 I think its a great idea. This would make it easier for new contributors to run tests and also make it easier for committers to verify a patch doesn't break functionality. On Tue, May 28, 2019 at 12:34 PM Priyank Porwal wrote: > Hi, > > What do you guys think about this work to setup Travis-CI and CodeCoverage > for Phoenix? The objective would be to run unit and integration tests on > each PR, show code-coverage reports and perhaps also do checkstyle checks > (after initial scrubbing effort). This would help rid of manual patch > uploads that we need currently, plus bring visibility into code health. > Thoughts? > > https://issues.apache.org/jira/browse/PHOENIX-4863 > > Thanks, > Priyank >
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272-4.x.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: PHOENIX-4863: Setup Travis-CI & CodeCoverage
What IT would you suggest to run? Testsuite (including long IT) takes ~2h. On Tue, 28 May 2019, 20:40 Thomas D'Silva, wrote: > +1 I think its a great idea. This would make it easier for new contributors > to run tests > and also make it easier for committers to verify a patch doesn't break > functionality. > > On Tue, May 28, 2019 at 12:34 PM Priyank Porwal > wrote: > > > Hi, > > > > What do you guys think about this work to setup Travis-CI and > CodeCoverage > > for Phoenix? The objective would be to run unit and integration tests on > > each PR, show code-coverage reports and perhaps also do checkstyle checks > > (after initial scrubbing effort). This would help rid of manual patch > > uploads that we need currently, plus bring visibility into code health. > > Thoughts? > > > > https://issues.apache.org/jira/browse/PHOENIX-4863 > > > > Thanks, > > Priyank > > >
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: (was: PHOENIX-5272.patch) > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: PHOENIX-4863: Setup Travis-CI & CodeCoverage
+1 It would be awesome to be able to do this. Any concerns if we choose to run long IT as part of this setup? On Tue, May 28, 2019 at 1:00 PM Pedro Boado wrote: > What IT would you suggest to run? Testsuite (including long IT) takes ~2h. > > On Tue, 28 May 2019, 20:40 Thomas D'Silva, .invalid> > wrote: > > > +1 I think its a great idea. This would make it easier for new > contributors > > to run tests > > and also make it easier for committers to verify a patch doesn't break > > functionality. > > > > On Tue, May 28, 2019 at 12:34 PM Priyank Porwal > > > wrote: > > > > > Hi, > > > > > > What do you guys think about this work to setup Travis-CI and > > CodeCoverage > > > for Phoenix? The objective would be to run unit and integration tests > on > > > each PR, show code-coverage reports and perhaps also do checkstyle > checks > > > (after initial scrubbing effort). This would help rid of manual patch > > > uploads that we need currently, plus bring visibility into code health. > > > Thoughts? > > > > > > https://issues.apache.org/jira/browse/PHOENIX-4863 > > > > > > Thanks, > > > Priyank > > > > > >
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: (was: PHOENIX-5272.patch) > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: PHOENIX-4863: Setup Travis-CI & CodeCoverage
I don't know much about this particular tool, but something like this would be good. Our current toolchain, with HadoopQA needing a JIRA patch and our code reviews mostly migrating to Github is really awkward to deal with, so TravisCI's Github integration's a definite plus. An example of Tephra's integration is here[1]: and on TravisCI's home page[2] they mention that open source projects are free. Assuming there are no licensing, scalability or implementation gotchas I'd be a +1. Geoffrey [1] https://travis-ci.org/apache/incubator-tephra [2] https://travis-ci.org/ On Tue, May 28, 2019 at 1:31 PM William Shen wrote: > +1 It would be awesome to be able to do this. > Any concerns if we choose to run long IT as part of this setup? > > On Tue, May 28, 2019 at 1:00 PM Pedro Boado wrote: > > > What IT would you suggest to run? Testsuite (including long IT) takes > ~2h. > > > > On Tue, 28 May 2019, 20:40 Thomas D'Silva, > .invalid> > > wrote: > > > > > +1 I think its a great idea. This would make it easier for new > > contributors > > > to run tests > > > and also make it easier for committers to verify a patch doesn't break > > > functionality. > > > > > > On Tue, May 28, 2019 at 12:34 PM Priyank Porwal < > priyankpor...@gmail.com > > > > > > wrote: > > > > > > > Hi, > > > > > > > > What do you guys think about this work to setup Travis-CI and > > > CodeCoverage > > > > for Phoenix? The objective would be to run unit and integration tests > > on > > > > each PR, show code-coverage reports and perhaps also do checkstyle > > checks > > > > (after initial scrubbing effort). This would help rid of manual patch > > > > uploads that we need currently, plus bring visibility into code > health. > > > > Thoughts? > > > > > > > > https://issues.apache.org/jira/browse/PHOENIX-4863 > > > > > > > > Thanks, > > > > Priyank > > > > > > > > > >
[ANNOUNCE] New committer Swaroopa Kadam
On behalf of the Apache Phoenix PMC, I am pleased to announce that Swaroopa Kadam has accepted our invitation to become a Phoenix committer. Swaroopa has contributed to a number of areas in the project, including the query server[1] and been an active participant in many code reviews for others' patches. Congratulations, Swaroopa, and we look forward to many more great contributions from you! Geoffrey Jacoby [1] - https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa)
Re: PHOENIX-4863: Setup Travis-CI & CodeCoverage
I assume we want to run all the ITs. Whevenver a PR is created Travis CI will automatically runs all the tests and post the results to the PR. On Tue, May 28, 2019 at 2:08 PM Geoffrey Jacoby wrote: > I don't know much about this particular tool, but something like this would > be good. > > Our current toolchain, with HadoopQA needing a JIRA patch and our code > reviews mostly migrating to Github is really awkward to deal with, so > TravisCI's Github integration's a definite plus. > > An example of Tephra's integration is here[1]: and on TravisCI's home > page[2] they mention that open source projects are free. > > Assuming there are no licensing, scalability or implementation gotchas I'd > be a +1. > > Geoffrey > > [1] https://travis-ci.org/apache/incubator-tephra > [2] https://travis-ci.org/ > > On Tue, May 28, 2019 at 1:31 PM William Shen > wrote: > > > +1 It would be awesome to be able to do this. > > Any concerns if we choose to run long IT as part of this setup? > > > > On Tue, May 28, 2019 at 1:00 PM Pedro Boado wrote: > > > > > What IT would you suggest to run? Testsuite (including long IT) takes > > ~2h. > > > > > > On Tue, 28 May 2019, 20:40 Thomas D'Silva, > > .invalid> > > > wrote: > > > > > > > +1 I think its a great idea. This would make it easier for new > > > contributors > > > > to run tests > > > > and also make it easier for committers to verify a patch doesn't > break > > > > functionality. > > > > > > > > On Tue, May 28, 2019 at 12:34 PM Priyank Porwal < > > priyankpor...@gmail.com > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > What do you guys think about this work to setup Travis-CI and > > > > CodeCoverage > > > > > for Phoenix? The objective would be to run unit and integration > tests > > > on > > > > > each PR, show code-coverage reports and perhaps also do checkstyle > > > checks > > > > > (after initial scrubbing effort). This would help rid of manual > patch > > > > > uploads that we need currently, plus bring visibility into code > > health. > > > > > Thoughts? > > > > > > > > > > https://issues.apache.org/jira/browse/PHOENIX-4863 > > > > > > > > > > Thanks, > > > > > Priyank > > > > > > > > > > > > > > >
Re: [ANNOUNCE] New committer Swaroopa Kadam
Congrats Swaroopa, keep up the great work! On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby wrote: > On behalf of the Apache Phoenix PMC, I am pleased to announce that Swaroopa > Kadam has accepted our invitation to become a Phoenix committer. Swaroopa > has contributed to a number of areas in the project, including the query > server[1] and been an active participant in many code reviews for others' > patches. > > Congratulations, Swaroopa, and we look forward to many more great > contributions from you! > > Geoffrey Jacoby > > [1] - > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa) >
[jira] [Created] (PHOENIX-5305) Move expression function tests to the right folder
Xinyi Yan created PHOENIX-5305:
--
Summary: Move expression function tests to the right folder
Key: PHOENIX-5305
URL: https://issues.apache.org/jira/browse/PHOENIX-5305
Project: Phoenix
Issue Type: Improvement
Reporter: Xinyi Yan
Assignee: Xinyi Yan
As [~chenglei] discovered on the other Jira, many phoenix expression function
tests are not under the right folder. Put function tests under the package
`{{org.apache.phoenix.expression.function}} ` instead of
`{{org.apache.phoenix.expression}}` for better code quality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache
[ https://issues.apache.org/jira/browse/PHOENIX-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-5231: -- Attachment: 5231-services-fix.patch > Configurable Stats Cache > > > Key: PHOENIX-5231 > URL: https://issues.apache.org/jira/browse/PHOENIX-5231 > Project: Phoenix > Issue Type: Test >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, > 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, > PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, > PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch > > Time Spent: 8h 40m > Remaining Estimate: 0h > > Currently, the phoenix stats cache is per > ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached > entry (the guideposts) and waste resources if these separate connections are > querying the same underlying table. It would be good to be able to provide a > configurable stats cache as control the cache level so it could be per JVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache
[ https://issues.apache.org/jira/browse/PHOENIX-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-5231: -- Attachment: 5231-services-fix.patch > Configurable Stats Cache > > > Key: PHOENIX-5231 > URL: https://issues.apache.org/jira/browse/PHOENIX-5231 > Project: Phoenix > Issue Type: Test >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, > 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, > PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, > PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch > > Time Spent: 8h 40m > Remaining Estimate: 0h > > Currently, the phoenix stats cache is per > ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached > entry (the guideposts) and waste resources if these separate connections are > querying the same underlying table. It would be good to be able to provide a > configurable stats cache as control the cache level so it could be per JVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache
[ https://issues.apache.org/jira/browse/PHOENIX-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-5231: -- Attachment: (was: 5231-services-fix.patch) > Configurable Stats Cache > > > Key: PHOENIX-5231 > URL: https://issues.apache.org/jira/browse/PHOENIX-5231 > Project: Phoenix > Issue Type: Test >Reporter: Daniel Wong >Assignee: Daniel Wong >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, > 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, > PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, > PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch > > Time Spent: 8h 40m > Remaining Estimate: 0h > > Currently, the phoenix stats cache is per > ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached > entry (the guideposts) and waste resources if these separate connections are > querying the same underlying table. It would be good to be able to provide a > configurable stats cache as control the cache level so it could be per JVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[ANNOUNCE] Apache Phoenix 4.14.2 released
The Apache Phoenix team is pleased to announce the immediate availability of the 4.14.2 patch release. Apache Phoenix enables SQL-based OLTP and operational analytics for Apache Hadoop using Apache HBase as its backing store and providing integration with other projects in the Apache ecosystem such as Spark, Hive, Pig, Flume, and MapReduce. This patch release has feature parity with supported HBase versions and includes critical bug fixes for secondary indexes. Download source and binaries here [1]. Thanks, Thomas (on behalf of the Apache Phoenix team) [1] http://phoenix.apache.org/download.html
Re: [ANNOUNCE] New committer Swaroopa Kadam
Congratulations Swaroopa! On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby wrote: > On behalf of the Apache Phoenix PMC, I am pleased to announce that Swaroopa > Kadam has accepted our invitation to become a Phoenix committer. Swaroopa > has contributed to a number of areas in the project, including the query > server[1] and been an active participant in many code reviews for others' > patches. > > Congratulations, Swaroopa, and we look forward to many more great > contributions from you! > > Geoffrey Jacoby > > [1] - > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa) > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [ANNOUNCE] New committer Swaroopa Kadam
Congrats Swaroopa! On Tue, May 28, 2019, 3:24 PM Andrew Purtell wrote: > Congratulations Swaroopa! > > On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby > wrote: > > > On behalf of the Apache Phoenix PMC, I am pleased to announce that > Swaroopa > > Kadam has accepted our invitation to become a Phoenix committer. Swaroopa > > has contributed to a number of areas in the project, including the query > > server[1] and been an active participant in many code reviews for others' > > patches. > > > > Congratulations, Swaroopa, and we look forward to many more great > > contributions from you! > > > > Geoffrey Jacoby > > > > [1] - > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa) > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: (was: PHOENIX-5272-4.x.patch) > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: (was: PHOENIX-5272.patch) > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5272) Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async
[ https://issues.apache.org/jira/browse/PHOENIX-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-5272: - Attachment: PHOENIX-5272-4.x.patch > Support ALTER INDEX REBUILD ALL ASYNC to fully rebuild global indexes async > --- > > Key: PHOENIX-5272 > URL: https://issues.apache.org/jira/browse/PHOENIX-5272 > Project: Phoenix > Issue Type: Bug >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-5272-4.x.patch, PHOENIX-5272.patch > > > This Jira is part of PHOENIX-4703. On 4703, a flag to IndexTool is added so > that we can delete all global indexes before rebuilding. This Jira is > concentrated on ALTER INDEX REBUILD ALL sql syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [ANNOUNCE] New committer Swaroopa Kadam
Congrats! :) On Tue, May 28, 2019 at 4:18 PM Priyank Porwal wrote: > Congrats Swaroopa! > > On Tue, May 28, 2019, 3:24 PM Andrew Purtell wrote: > > > Congratulations Swaroopa! > > > > On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby > > wrote: > > > > > On behalf of the Apache Phoenix PMC, I am pleased to announce that > > Swaroopa > > > Kadam has accepted our invitation to become a Phoenix committer. > Swaroopa > > > has contributed to a number of areas in the project, including the > query > > > server[1] and been an active participant in many code reviews for > others' > > > patches. > > > > > > Congratulations, Swaroopa, and we look forward to many more great > > > contributions from you! > > > > > > Geoffrey Jacoby > > > > > > [1] - > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa) > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk > > >
Re: [ANNOUNCE] New committer Swaroopa Kadam
Congrats Swaroopa, looking forward to more patches On Tue, May 28, 2019 at 4:33 PM Xu Cang wrote: > Congrats! :) > > On Tue, May 28, 2019 at 4:18 PM Priyank Porwal > wrote: > > > Congrats Swaroopa! > > > > On Tue, May 28, 2019, 3:24 PM Andrew Purtell > wrote: > > > > > Congratulations Swaroopa! > > > > > > On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby > > > wrote: > > > > > > > On behalf of the Apache Phoenix PMC, I am pleased to announce that > > > Swaroopa > > > > Kadam has accepted our invitation to become a Phoenix committer. > > Swaroopa > > > > has contributed to a number of areas in the project, including the > > query > > > > server[1] and been an active participant in many code reviews for > > others' > > > > patches. > > > > > > > > Congratulations, Swaroopa, and we look forward to many more great > > > > contributions from you! > > > > > > > > Geoffrey Jacoby > > > > > > > > [1] - > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa) > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk > > > > > >
