[
https://issues.apache.org/jira/browse/PHOENIX-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706935#comment-14706935
]
Josh Mahonin commented on PHOENIX-2169:
---------------------------------------
I've reduced the for-loops down to 10 rows upserted per table, which still
usually results in a failure. Although I'm mostly seeing
ArrayIndexOutOfBoundsExceptions, I'm occasionally seeing this as well:
{noformat}
java.sql.SQLException: ERROR 218 (22018): Constraint violatioin. ERROR 218
(22018): Constraint violatioin. DEST.PK3 may not be null
at
org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:389)
at
org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
at
org.apache.phoenix.util.ServerUtil.parseRemoteException(ServerUtil.java:131)
at
org.apache.phoenix.util.ServerUtil.parseServerExceptionOrNull(ServerUtil.java:115)
at
org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:104)
at
org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:553)
at
org.apache.phoenix.iterate.MergeSortResultIterator.getIterators(MergeSortResultIterator.java:48)
at
org.apache.phoenix.iterate.MergeSortResultIterator.minIterator(MergeSortResultIterator.java:84)
at
org.apache.phoenix.iterate.MergeSortResultIterator.next(MergeSortResultIterator.java:111)
at
org.apache.phoenix.iterate.DelegateResultIterator.next(DelegateResultIterator.java:44)
at
org.apache.phoenix.compile.UpsertCompiler$2.execute(UpsertCompiler.java:685)
at
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:319)
at
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:311)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:309)
at
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1432)
at
org.apache.phoenix.end2end.salted.SaltedTableUpsertSelectIT.testUpsertSelectWithJoinOnSaltedTables(SaltedTableUpsertSelectIT.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
> Illegal data error on UPSERT SELECT and JOIN with salted tables
> ---------------------------------------------------------------
>
> Key: PHOENIX-2169
> URL: https://issues.apache.org/jira/browse/PHOENIX-2169
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.5.0
> Reporter: Josh Mahonin
> Attachments: PHOENIX-2169-bug.patch
>
>
> I have an issue where I get periodic failures (~50%) for an UPSERT SELECT
> query involving a JOIN on salted tables. Unfortunately I haven't been able to
> create a reproducible test case yet, though I'll keep trying. I believe this
> same behaviour existed in 4.3.1 as well, so I don't think it's a regression.
> The upsert query itself looks something like this:
> {code}
> UPSERT INTO a(tid, ds, etp, eid, ts, atp, rel, tp, tpid, dt, pro)
> SELECT c.tid,
> c.ds,
> c.etp,
> c.eid,
> c.dh,
> 0,
> c.rel,
> c.tp,
> c.tpid,
> current_time(),
> 1.0 / s.th
> FROM e_c c
> join e_s s
> ON s.tid = c.tid
> AND s.ds = c.ds
> AND s.etp = c.etp
> AND s.eid = c.eid
> WHERE c.tid = 'FOO';
> {code}
> Without the upsert, the query always returns the right data, but with the
> upsert, it ends up with failures like:
> Error: ERROR 201 (22000): Illegal data. ERROR 201 (22000): Illegal data.
> Expected length of at least 109 bytes, but had 19 (state=22000,code=201)
> The explain plan looks like:
> {code}
> UPSERT SELECT
> CLIENT 16-CHUNK PARALLEL 16-WAY RANGE SCAN OVER E_C [0,'FOO']
> SERVER FILTER BY FIRST KEY ONLY
> PARALLEL INNER-JOIN TABLE 0
> CLIENT 16-CHUNK PARALLEL 16-WAY FULL SCAN OVER E_S
> DYNAMIC SERVER FILTER BY (C.TID, C.DS, C.ETP, C.EID) IN ((S.TID, S.DS,
> S.ETP, S.EID))
> {code}
> I'm using SALT_BUCKETS=16 for both tables in the join, and this is a dev
> environment, so only 1 region server. Note that without salted tables, I have
> no issue with this query.
> The number of rows in E_C is around 23K, and the number of rows in E_S is 62.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
