[
https://issues.apache.org/jira/browse/CALCITE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935615#comment-14935615
]
Josh Elser commented on CALCITE-903:
------------------------------------
High-level before I get a patch put up here... I think my approach would fall
into your 3rd point. Client can recover when a server responds in a certain way
(because it doesn't have the necessary state). I liked this approach because it
let me reuse a bunch of the existing RPC logic instead of trying to re-hash how
Fetch fundamentally works. On the client it's more or less:
{code}
while(true) {
try {
fetch();
return;
} catch (missing_state_1) {
reset_necessary_state1();
continue;
} catch (missing_state_2) {
reset_necessary_state2();
continue;
}
}
{code}
* Introduced a new attribute sent back to the client to denote that the
requested statement doesn't exist and that the client should create a new
Statement.
* Introduced a new attribute sent back to the client to denote that the
requests ResultSet (on a Statement) doesn't exist and the client needs to
"recreate" that ResultSet on the server.
* Introduced a new RPC method to recreate the ResultSet in the server (either
created by a DatabaseMetaData operation or some SQL) that a client can call
when FetchResponse contains a new attribute (said attribute is essentially a
marker for the client to know that it should call this new RPC method). Aside:
I think there might be a way to actually work around a new RPC method, but we
can chat that over when I post some code :)
> 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)
