[
https://issues.apache.org/jira/browse/CALCITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281733#comment-17281733
]
Stamatis Zampetakis commented on CALCITE-4489:
----------------------------------------------
Hi [~vlads], thanks for providing the test case. Is this an exact repro from
the use-case you observed in your project?
Looking into the test code there some things that surprise me a bit one being
the {{LocalService}} which is instantiated
([https://github.com/skarzhevskyy/calcite-avatica-concurrency-test/blob/2d19b16bcb8cd17744319bf412ab3b4c676da490/src/test/java/org/apache/calcite/jdbc/HttpTest.java#L94)]
with a {{CalciteMetaImpl}} and a {{CalciteConnectionImpl}} which basically
means that you are hitting the same "server side" connection every time. The
CalciteConnectionImpl is not thread-safe so getting into race conditions is not
so surprising.
> Avatica JdbcMeta statement IDs Concurrency problem
> --------------------------------------------------
>
> Key: CALCITE-4489
> URL: https://issues.apache.org/jira/browse/CALCITE-4489
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.26.0
> Reporter: Vlad Skarzhevskyy
> Priority: Major
> Attachments: LoadAllData.java, stak-trace-v2.txt, stak-trace.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We encountered the JdbcMeta statement IDs concurrency problems that lead to
> errors pulling the data from avatica JDBC remote http server under heavy load.
> The error stack trace for the error is attached.
>
> Our setup: Avatica JDBC remote http server handled by Calcite on the
> server side.
> For the record we had not been able to reproduce the same problems with
> Avatica, only remote proxy connected directly to DB.
>
> We believe that the cause of the problem is unsynchronized increment of
> connection.statementCount
> see MetaImpl.createStatement
> [https://github.com/apache/calcite-avatica/blob/master/core/src/main/java/org/apache/calcite/avatica/MetaImpl.java#L213]
> {code:java}
> public StatementHandle createStatement(ConnectionHandle ch) {
> return new StatementHandle(ch.id, connection.statementCount++, null);
> }{code}
> Suggested fix is to use AtomicInteger for statementCount.
> Our stress tests show that the problem is resolved by the fix..
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
