[jira] [Commented] (CALCITE-903) Enable client to recover from missing server-side state

["Josh Elser (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935488#comment-14935488 ] 

Josh Elser commented on CALCITE-903:
------------------------------------

I've been hacking on a prototype to enable this by starting two PQS instances, and making a dirty hack to the client to randomly choose one server or the other. The expected outcome is that the client should see the same results, regardless of which PQS instance actually returned the results. This goes as far to have PQS1 return the first frame, and PQS2 returns the rest of the frames. I have some initial queries working, but need to write many more tests before I feel comfortable with it.

> Enable client to recover from missing server-side state
> -------------------------------------------------------
>
>                 Key: CALCITE-903
>                 URL: https://issues.apache.org/jira/browse/CALCITE-903
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.5.0-incubating
>
>
> When deploying more than one instance of an avatica-server, we have the desire to treat the collection of servers as a single server. Ideally, we want to have the avatica-client operate in a manner that doesn't expect a server to have specific state For example, the avatica-client should be able to know that when a server doesn't have a statement with the ID the client thinks it should, the client can create a new statement.
> This is desirable because it allows us to use a generic load-balancer between clients and servers without the need for clustering or sticky sessions. The downside is that in the face of failure, operations will take longer than normal. Even with the performance hit, as long as an avatica-server exists, the client can still retrieve the results for some query which is ideal (tl;dr it will take longer, but the client still gets the answer).
> Two major areas that need to be addressed presently are:
> 1. Automatic recreation of Statements when they are not cached
> 2. Recreation of ResultSets to resume iteration (for fetch()). This depends on "stable results" by the underlying JDBC driver, otherwise external synchronization would be required. This is considered a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)