[
https://issues.apache.org/jira/browse/CALCITE-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940588#comment-14940588
]
Julian Hyde commented on CALCITE-906:
-------------------------------------
For what it's worth, this fix does *not* solve the intermittent problem in the
test suite. Against 777f780 I just got this: {noformat}Tests run: 40, Failures:
1, Errors: 0, Skipped: 4, Time elapsed: 2.152 sec <<< FAILURE! - in
org.apache.calcite.avatica.RemoteDriverTest
testConnectionIsolation[0](org.apache.calcite.avatica.RemoteDriverTest) Time
elapsed: 0.027 sec <<< FAILURE!
java.lang.AssertionError: statement creation implicitly creates a connection
server-side expected:<2> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at
org.apache.calcite.avatica.RemoteDriverTest.testConnectionIsolation(RemoteDriverTest.java:749)
{noformat}
[~janvanbesien] Do you actually have a test case for this issue?
> Avatica JdbcMeta statement IDs are not unique
> ---------------------------------------------
>
> Key: CALCITE-906
> URL: https://issues.apache.org/jira/browse/CALCITE-906
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Jan Van Besien
> Assignee: Julian Hyde
> Attachments: CALCITE-906.patch
>
>
> There seems to be a concurrency-related problem with the statementId that is
> generated in the JdbcMeta#createStatement for statements in the
> statementCache.
> We use avatica to create a driver which uses the remote RPC protocol to wrap
> an existing jdbc driver on the server. We have a test which performs
> concurrent queries on multiple connections (using apache commons-pool) which
> fails often.
> If it fails, the following two things are always observed:
> * A java.lang.AssertionError on the assert in Meta#count(String connectionId,
> int statementId, long updateCount), resulting in the server to send a http
> 500.
> * When logging all used connectionId's and statementId's, I observe the same
> statementId to be re-used for different connectionId's.
> I don't know exactly how these two problems are related, but it looks like
> statementId's are supposed to be unique and currently they are not.
> The current approach is to use System.identityHashCode(statement) to
> calculate a statementId. Simply replacing this with a random int seems to
> solve the problem.
> Depending on what the actual uniqueness requirements for the statementId are,
> a UUID might be even better (but will have impact on the RPC) or an
> AtomicInteger.
> I'll attach a patch for the random int fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
