[
https://issues.apache.org/jira/browse/CALCITE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14937023#comment-14937023
]
Josh Elser commented on CALCITE-903:
------------------------------------
Prelim-patch (PR) incoming once I get the existing unit tests passing. Of
technologically cool note: I started two phoenix queryserver instances and put
them behind HAProxy and started doing some local tests. Running a query via
sqlline that pulled by 25k results, I killed one PQS, and then the client
automatically started pulling the rest of the results from the other PQS. I
didn't do any more correctness testing other than sqlline reporting 25k
results, but I was pleased to see it.
Example haproxy configuration I used, pointing sqlline at localhost:8888.
{{balance source}} was the big win which pushes a client to a specific server
as long as the state of servers doesn't change. This helps ensure that we don't
bounce around to servers recreating state everywhere (as a round-robin approach
would likely spin indefinitely).
{noformat}
global
maxconn 256
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend http-in
bind *:8888
default_backend servers
backend servers
balance source
server server1 127.0.0.1:8765 check
server server2 127.0.0.1:8766 check
{noformat}
> 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)
