[jira] [Updated] (PHOENIX-4849) Phoenix may incorrectly replace TableResultIterators after HBase region splits
[ https://issues.apache.org/jira/browse/PHOENIX-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4849: --- Summary: Phoenix may incorrectly replace TableResultIterators after HBase region splits (was: Phoenix may generate incorrectly replace TableResultIterators after HBase region splits) > Phoenix may incorrectly replace TableResultIterators after HBase region splits > -- > > Key: PHOENIX-4849 > URL: https://issues.apache.org/jira/browse/PHOENIX-4849 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Akshita Malhotra >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 4.15.0, 4.14.1, 5.1.0 > > Attachments: PHOENIX-4849-4.x-HBase-1.4-v6.patch, > PHOENIX-4849-4.x-HBase-1.4-v7.patch, PHOENIX-4849-4.x-HBase-1.4.05.patch, > PHOENIX-4849-all.patch, PHOENIX-4849-complete-1.4.txt, PHOENIX-4849-fix.txt, > PHOENIX-4849-master-v7.patch, PHOENIX-4849-v2.patch, PHOENIX-4849-v3.patch, > PHOENIX-4849-v4.patch, PHOENIX-4849-v5.patch, PHOENIX-4849.patch, > SerialIterators.diff, SplitIT.patch > > > UPSERT SELECT throws a StaleRegionBoundaryCacheException immediately after a > split. On the other hand, an upsert followed by a select for example works > absolutely fine > org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR 1108 > (XCL08): Cache of region boundaries are out of date. > at > org.apache.phoenix.exception.SQLExceptionCode$14.newException(SQLExceptionCode.java:365) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:183) > at > org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:167) > at > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:134) > at > org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:153) > at > org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:228) > at > org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:47) > at > org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:59) > at > org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:73) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.nextIterator(SerialIterators.java:187) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.currentIterator(SerialIterators.java:160) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.peek(SerialIterators.java:218) > at > org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:100) > at > org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:117) > at > org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44) > at > org.apache.phoenix.iterate.LimitingResultIterator.next(LimitingResultIterator.java:47) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:805) > at > org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:219) > at > org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1292) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:173) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:183) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.upsertSelectData1(UpsertSelectAfterSplitTest.java:109) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.testUpsertSelect(UpsertSelectAfterSplitTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at >
Re: [DISCUSS] Next 5.x release?
You're right, Josh, I was mistaken, there was indeed a 5.0.0 release. But I meant the same as your last bit - branch off 5.0.0 and only put in HBase 2.0.2 and critical fixes for 5.0.1. On Wed, Sep 26, 2018 at 6:40 PM Josh Elser wrote: > No, Vincent, that is wrong. There *was* a 5.0.0-alpha release. Then, > there was a 5.0.0 release (not called alpha). > > To Thomas' original question: I don't think we need to keep 4.15 in > lock-step with 5.x, but if 5.x isn't ready for release for the same > reason 4.15 is not ready for release, then we should hold off on another > 5.x (from the master branch). > > In a similar vein, we could also branch off of the 5.0.0 release and > cherry-pick back critical changes to make a proper 5.0.1 if a 5.1.0 is > still a ways off (as above) > > On 9/26/18 6:18 PM, Vincent Poon wrote: > > The 5.0.0 release apparently was an 'alpha'. I think we should do a > 5.0.1 > > which can work with HBase 2.0.2 and remove the 'alpha'. > > 5.0 has feature parity with 4.14. > > 5.1 would have feature parity with 4.15, the main addition being > splittable > > syscat > > > > On a sidenote, I've been planning a 4.14.1 release but was waiting for > the > > CDH builds. It looks like CDH branches are no longer being maintained > so I > > think I can just move forward with that. (btw we should clean those up) > > > > If noone else is doing it, I can try doing the 5.0.1 release > concurrently. > > > > On Wed, Sep 26, 2018 at 3:01 PM Andrew Purtell > wrote: > > > >> If possible please continue to release for one or more of the HBase 1.x > >> code lines. I have a feeling the HBase 1.xes will be in production for a > >> long time yet. > >> > >> On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva > > >> wrote: > >> > >>> Would we also release 4.15, or just a new 5.x release to support HBase > >>> 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are needed > for > >>> splittable system catalog. > >>> > >>> On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser wrote: > >>> > On the user@phoenix list, Francis pointed out how Phoenix 5.0.0 only > works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is pretty bad > given > >>> the > big fixes that went in since 2.0.0. > > What do folks think about a new 5.x release? Is it worthwhile to bring > back a reduced set of commits and make a 5.0.1? Or just release a > 5.1.0 > >>> and > ask people to move to that instead? > > - Josh > > >>> > >> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >> > > >
Re: [DISCUSS] Next 5.x release?
No, Vincent, that is wrong. There *was* a 5.0.0-alpha release. Then, there was a 5.0.0 release (not called alpha). To Thomas' original question: I don't think we need to keep 4.15 in lock-step with 5.x, but if 5.x isn't ready for release for the same reason 4.15 is not ready for release, then we should hold off on another 5.x (from the master branch). In a similar vein, we could also branch off of the 5.0.0 release and cherry-pick back critical changes to make a proper 5.0.1 if a 5.1.0 is still a ways off (as above) On 9/26/18 6:18 PM, Vincent Poon wrote: The 5.0.0 release apparently was an 'alpha'. I think we should do a 5.0.1 which can work with HBase 2.0.2 and remove the 'alpha'. 5.0 has feature parity with 4.14. 5.1 would have feature parity with 4.15, the main addition being splittable syscat On a sidenote, I've been planning a 4.14.1 release but was waiting for the CDH builds. It looks like CDH branches are no longer being maintained so I think I can just move forward with that. (btw we should clean those up) If noone else is doing it, I can try doing the 5.0.1 release concurrently. On Wed, Sep 26, 2018 at 3:01 PM Andrew Purtell wrote: If possible please continue to release for one or more of the HBase 1.x code lines. I have a feeling the HBase 1.xes will be in production for a long time yet. On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva wrote: Would we also release 4.15, or just a new 5.x release to support HBase 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are needed for splittable system catalog. On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser wrote: On the user@phoenix list, Francis pointed out how Phoenix 5.0.0 only works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is pretty bad given the big fixes that went in since 2.0.0. What do folks think about a new 5.x release? Is it worthwhile to bring back a reduced set of commits and make a 5.0.1? Or just release a 5.1.0 and ask people to move to that instead? - Josh -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Updated] (PHOENIX-4930) Add test for a simple SELECT query during a split
[ https://issues.apache.org/jira/browse/PHOENIX-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4930: Attachment: PHOENIX-4930.patch > Add test for a simple SELECT query during a split > - > > Key: PHOENIX-4930 > URL: https://issues.apache.org/jira/browse/PHOENIX-4930 > Project: Phoenix > Issue Type: Test >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4930.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4930) Add test for a simple SELECT query during a split
Thomas D'Silva created PHOENIX-4930: --- Summary: Add test for a simple SELECT query during a split Key: PHOENIX-4930 URL: https://issues.apache.org/jira/browse/PHOENIX-4930 Project: Phoenix Issue Type: Test Reporter: Thomas D'Silva Assignee: Thomas D'Silva Fix For: 4.15.0, 5.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Next 5.x release?
The 5.0.0 release apparently was an 'alpha'. I think we should do a 5.0.1 which can work with HBase 2.0.2 and remove the 'alpha'. 5.0 has feature parity with 4.14. 5.1 would have feature parity with 4.15, the main addition being splittable syscat On a sidenote, I've been planning a 4.14.1 release but was waiting for the CDH builds. It looks like CDH branches are no longer being maintained so I think I can just move forward with that. (btw we should clean those up) If noone else is doing it, I can try doing the 5.0.1 release concurrently. On Wed, Sep 26, 2018 at 3:01 PM Andrew Purtell wrote: > If possible please continue to release for one or more of the HBase 1.x > code lines. I have a feeling the HBase 1.xes will be in production for a > long time yet. > > On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva > wrote: > > > Would we also release 4.15, or just a new 5.x release to support HBase > > 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are needed for > > splittable system catalog. > > > > On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser wrote: > > > > > On the user@phoenix list, Francis pointed out how Phoenix 5.0.0 only > > > works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is pretty bad given > > the > > > big fixes that went in since 2.0.0. > > > > > > What do folks think about a new 5.x release? Is it worthwhile to bring > > > back a reduced set of commits and make a 5.0.1? Or just release a 5.1.0 > > and > > > ask people to move to that instead? > > > > > > - Josh > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
Re: [DISCUSS] Next 5.x release?
If possible please continue to release for one or more of the HBase 1.x code lines. I have a feeling the HBase 1.xes will be in production for a long time yet. On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva wrote: > Would we also release 4.15, or just a new 5.x release to support HBase > 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are needed for > splittable system catalog. > > On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser wrote: > > > On the user@phoenix list, Francis pointed out how Phoenix 5.0.0 only > > works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is pretty bad given > the > > big fixes that went in since 2.0.0. > > > > What do folks think about a new 5.x release? Is it worthwhile to bring > > back a reduced set of commits and make a 5.0.1? Or just release a 5.1.0 > and > > ask people to move to that instead? > > > > - Josh > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
[jira] [Updated] (PHOENIX-4929) IndexOutOfBoundsException when casting timestamp to date
[ https://issues.apache.org/jira/browse/PHOENIX-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4929: -- Attachment: QueryCompilerTest.java > IndexOutOfBoundsException when casting timestamp to date > > > Key: PHOENIX-4929 > URL: https://issues.apache.org/jira/browse/PHOENIX-4929 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Priority: Major > Attachments: QueryCompilerTest.java > > > java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 > at java.util.ArrayList.rangeCheck(ArrayList.java:653) > at java.util.ArrayList.get(ArrayList.java:429) > at > org.apache.phoenix.expression.function.RoundTimestampExpression.create(RoundTimestampExpression.java:76) > at > org.apache.phoenix.compile.ExpressionCompiler.convertToRoundExpressionIfNeeded(ExpressionCompiler.java:594) > at > org.apache.phoenix.compile.ExpressionCompiler.visitLeave(ExpressionCompiler.java:621) > at > org.apache.phoenix.compile.ExpressionCompiler.visitLeave(ExpressionCompiler.java:1) > at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:62) > at > org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:412) > at > org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:564) > at > org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510) > at > org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195) > at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155) > at > org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:490) > at > org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:1) > at > org.apache.phoenix.jdbc.PhoenixStatement.compileQuery(PhoenixStatement.java:1745) > at > org.apache.phoenix.jdbc.PhoenixStatement.compileQuery(PhoenixStatement.java:1738) > at -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4929) IndexOutOfBoundsException when casting timestamp to date
Vincent Poon created PHOENIX-4929: - Summary: IndexOutOfBoundsException when casting timestamp to date Key: PHOENIX-4929 URL: https://issues.apache.org/jira/browse/PHOENIX-4929 Project: Phoenix Issue Type: Bug Affects Versions: 4.14.0 Reporter: Vincent Poon java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.phoenix.expression.function.RoundTimestampExpression.create(RoundTimestampExpression.java:76) at org.apache.phoenix.compile.ExpressionCompiler.convertToRoundExpressionIfNeeded(ExpressionCompiler.java:594) at org.apache.phoenix.compile.ExpressionCompiler.visitLeave(ExpressionCompiler.java:621) at org.apache.phoenix.compile.ExpressionCompiler.visitLeave(ExpressionCompiler.java:1) at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:62) at org.apache.phoenix.compile.ProjectionCompiler.compile(ProjectionCompiler.java:412) at org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:564) at org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510) at org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195) at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155) at org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:490) at org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:1) at org.apache.phoenix.jdbc.PhoenixStatement.compileQuery(PhoenixStatement.java:1745) at org.apache.phoenix.jdbc.PhoenixStatement.compileQuery(PhoenixStatement.java:1738) at -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4097) Ensure new rows not seen if split occurs during UPSERT SELECT to same table
[ https://issues.apache.org/jira/browse/PHOENIX-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva resolved PHOENIX-4097. - Resolution: Fixed > Ensure new rows not seen if split occurs during UPSERT SELECT to same table > --- > > Key: PHOENIX-4097 > URL: https://issues.apache.org/jira/browse/PHOENIX-4097 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Priority: Major > > Since we're running at the latest time stamp during an UPSERT SELECT, we > should ensure that if a split occurs, we still do not see the new rows that > have been upsert. If that's not possible, we should likely fail the UPSERT > SELECT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Next 5.x release?
Would we also release 4.15, or just a new 5.x release to support HBase 2.0.1/2.0.2 ? PHOENIX-3534 has a few follow-up JIRAs that are needed for splittable system catalog. On Tue, Sep 25, 2018 at 7:56 PM, Josh Elser wrote: > On the user@phoenix list, Francis pointed out how Phoenix 5.0.0 only > works with HBase 2.0.0 and not 2.0.1 or 2.0.2. This is pretty bad given the > big fixes that went in since 2.0.0. > > What do folks think about a new 5.x release? Is it worthwhile to bring > back a reduced set of commits and make a 5.0.1? Or just release a 5.1.0 and > ask people to move to that instead? > > - Josh >
[jira] [Updated] (PHOENIX-4849) Phoenix may generate incorrectly replace TableResultIterators after HBase region splits
[ https://issues.apache.org/jira/browse/PHOENIX-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4849: --- Fix Version/s: 5.1.0 4.14.1 4.15.0 > Phoenix may generate incorrectly replace TableResultIterators after HBase > region splits > --- > > Key: PHOENIX-4849 > URL: https://issues.apache.org/jira/browse/PHOENIX-4849 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Akshita Malhotra >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 4.15.0, 4.14.1, 5.1.0 > > Attachments: PHOENIX-4849-4.x-HBase-1.4-v6.patch, > PHOENIX-4849-4.x-HBase-1.4-v7.patch, PHOENIX-4849-4.x-HBase-1.4.05.patch, > PHOENIX-4849-all.patch, PHOENIX-4849-complete-1.4.txt, PHOENIX-4849-fix.txt, > PHOENIX-4849-master-v7.patch, PHOENIX-4849-v2.patch, PHOENIX-4849-v3.patch, > PHOENIX-4849-v4.patch, PHOENIX-4849-v5.patch, PHOENIX-4849.patch, > SerialIterators.diff, SplitIT.patch > > > UPSERT SELECT throws a StaleRegionBoundaryCacheException immediately after a > split. On the other hand, an upsert followed by a select for example works > absolutely fine > org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR 1108 > (XCL08): Cache of region boundaries are out of date. > at > org.apache.phoenix.exception.SQLExceptionCode$14.newException(SQLExceptionCode.java:365) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:183) > at > org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:167) > at > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:134) > at > org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:153) > at > org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:228) > at > org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:47) > at > org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:59) > at > org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:73) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.nextIterator(SerialIterators.java:187) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.currentIterator(SerialIterators.java:160) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.peek(SerialIterators.java:218) > at > org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:100) > at > org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:117) > at > org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44) > at > org.apache.phoenix.iterate.LimitingResultIterator.next(LimitingResultIterator.java:47) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:805) > at > org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:219) > at > org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1292) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:173) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:183) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.upsertSelectData1(UpsertSelectAfterSplitTest.java:109) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.testUpsertSelect(UpsertSelectAfterSplitTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at
[jira] [Updated] (PHOENIX-4849) Phoenix may generate incorrectly replace TableResultIterators after HBase region splits
[ https://issues.apache.org/jira/browse/PHOENIX-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4849: --- Summary: Phoenix may generate incorrectly replace TableResultIterators after HBase region splits (was: UPSERT SELECT fails with stale region boundary exception after a split) > Phoenix may generate incorrectly replace TableResultIterators after HBase > region splits > --- > > Key: PHOENIX-4849 > URL: https://issues.apache.org/jira/browse/PHOENIX-4849 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Akshita Malhotra >Assignee: Lars Hofhansl >Priority: Critical > Attachments: PHOENIX-4849-4.x-HBase-1.4-v6.patch, > PHOENIX-4849-4.x-HBase-1.4-v7.patch, PHOENIX-4849-4.x-HBase-1.4.05.patch, > PHOENIX-4849-all.patch, PHOENIX-4849-complete-1.4.txt, PHOENIX-4849-fix.txt, > PHOENIX-4849-master-v7.patch, PHOENIX-4849-v2.patch, PHOENIX-4849-v3.patch, > PHOENIX-4849-v4.patch, PHOENIX-4849-v5.patch, PHOENIX-4849.patch, > SerialIterators.diff, SplitIT.patch > > > UPSERT SELECT throws a StaleRegionBoundaryCacheException immediately after a > split. On the other hand, an upsert followed by a select for example works > absolutely fine > org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR 1108 > (XCL08): Cache of region boundaries are out of date. > at > org.apache.phoenix.exception.SQLExceptionCode$14.newException(SQLExceptionCode.java:365) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:183) > at > org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:167) > at > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:134) > at > org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:153) > at > org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:228) > at > org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:47) > at > org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:59) > at > org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:73) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.nextIterator(SerialIterators.java:187) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.currentIterator(SerialIterators.java:160) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.peek(SerialIterators.java:218) > at > org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:100) > at > org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:117) > at > org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44) > at > org.apache.phoenix.iterate.LimitingResultIterator.next(LimitingResultIterator.java:47) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:805) > at > org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:219) > at > org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1292) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:173) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:183) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.upsertSelectData1(UpsertSelectAfterSplitTest.java:109) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.testUpsertSelect(UpsertSelectAfterSplitTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at >
[jira] [Updated] (PHOENIX-4849) UPSERT SELECT fails with stale region boundary exception after a split
[ https://issues.apache.org/jira/browse/PHOENIX-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4849: --- Attachment: PHOENIX-4849-master-v7.patch > UPSERT SELECT fails with stale region boundary exception after a split > -- > > Key: PHOENIX-4849 > URL: https://issues.apache.org/jira/browse/PHOENIX-4849 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Akshita Malhotra >Assignee: Lars Hofhansl >Priority: Critical > Attachments: PHOENIX-4849-4.x-HBase-1.4-v6.patch, > PHOENIX-4849-4.x-HBase-1.4-v7.patch, PHOENIX-4849-4.x-HBase-1.4.05.patch, > PHOENIX-4849-all.patch, PHOENIX-4849-complete-1.4.txt, PHOENIX-4849-fix.txt, > PHOENIX-4849-master-v7.patch, PHOENIX-4849-v2.patch, PHOENIX-4849-v3.patch, > PHOENIX-4849-v4.patch, PHOENIX-4849-v5.patch, PHOENIX-4849.patch, > SerialIterators.diff, SplitIT.patch > > > UPSERT SELECT throws a StaleRegionBoundaryCacheException immediately after a > split. On the other hand, an upsert followed by a select for example works > absolutely fine > org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR 1108 > (XCL08): Cache of region boundaries are out of date. > at > org.apache.phoenix.exception.SQLExceptionCode$14.newException(SQLExceptionCode.java:365) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:183) > at > org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:167) > at > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:134) > at > org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:153) > at > org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:228) > at > org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:47) > at > org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:59) > at > org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:73) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.nextIterator(SerialIterators.java:187) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.currentIterator(SerialIterators.java:160) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.peek(SerialIterators.java:218) > at > org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:100) > at > org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:117) > at > org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44) > at > org.apache.phoenix.iterate.LimitingResultIterator.next(LimitingResultIterator.java:47) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:805) > at > org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:219) > at > org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1292) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:173) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:183) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.upsertSelectData1(UpsertSelectAfterSplitTest.java:109) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.testUpsertSelect(UpsertSelectAfterSplitTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at >
[jira] [Updated] (PHOENIX-4849) UPSERT SELECT fails with stale region boundary exception after a split
[ https://issues.apache.org/jira/browse/PHOENIX-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4849: --- Attachment: PHOENIX-4849-4.x-HBase-1.4-v7.patch > UPSERT SELECT fails with stale region boundary exception after a split > -- > > Key: PHOENIX-4849 > URL: https://issues.apache.org/jira/browse/PHOENIX-4849 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Akshita Malhotra >Assignee: Lars Hofhansl >Priority: Critical > Attachments: PHOENIX-4849-4.x-HBase-1.4-v6.patch, > PHOENIX-4849-4.x-HBase-1.4-v7.patch, PHOENIX-4849-4.x-HBase-1.4.05.patch, > PHOENIX-4849-all.patch, PHOENIX-4849-complete-1.4.txt, PHOENIX-4849-fix.txt, > PHOENIX-4849-v2.patch, PHOENIX-4849-v3.patch, PHOENIX-4849-v4.patch, > PHOENIX-4849-v5.patch, PHOENIX-4849.patch, SerialIterators.diff, SplitIT.patch > > > UPSERT SELECT throws a StaleRegionBoundaryCacheException immediately after a > split. On the other hand, an upsert followed by a select for example works > absolutely fine > org.apache.phoenix.schema.StaleRegionBoundaryCacheException: ERROR 1108 > (XCL08): Cache of region boundaries are out of date. > at > org.apache.phoenix.exception.SQLExceptionCode$14.newException(SQLExceptionCode.java:365) > at > org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150) > at > org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:183) > at > org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:167) > at > org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:134) > at > org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:153) > at > org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:228) > at > org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:47) > at > org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:59) > at > org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:73) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.nextIterator(SerialIterators.java:187) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.currentIterator(SerialIterators.java:160) > at > org.apache.phoenix.iterate.SerialIterators$SerialIterator.peek(SerialIterators.java:218) > at > org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:100) > at > org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:117) > at > org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44) > at > org.apache.phoenix.iterate.LimitingResultIterator.next(LimitingResultIterator.java:47) > at org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:805) > at > org.apache.phoenix.compile.UpsertCompiler.upsertSelect(UpsertCompiler.java:219) > at > org.apache.phoenix.compile.UpsertCompiler$ClientUpsertSelectMutationPlan.execute(UpsertCompiler.java:1292) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408) > at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:173) > at > org.apache.phoenix.jdbc.PhoenixPreparedStatement.execute(PhoenixPreparedStatement.java:183) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.upsertSelectData1(UpsertSelectAfterSplitTest.java:109) > at > org.apache.phoenix.end2end.UpsertSelectAfterSplitTest.testUpsertSelect(UpsertSelectAfterSplitTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at >
[jira] [Created] (PHOENIX-4928) Local index is always in building state
Aman Poonia created PHOENIX-4928: Summary: Local index is always in building state Key: PHOENIX-4928 URL: https://issues.apache.org/jira/browse/PHOENIX-4928 Project: Phoenix Issue Type: Bug Affects Versions: 4.14.0 Environment: Phoenix 4.14 HBase 1.3 Reporter: Aman Poonia In some of our testing we found that local index is always in building state even when no writes are happening on table. This is misleading as someone might consider it has some operations running on the index. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
