The Phoenix thin client is 99.9% Avatica :)
The only real configuration that comes to mind is specifying the
"jdbc:phoenix:thin" jdbc url prefix
On 5/25/17 7:25 PM, Gian Merlino wrote:
I was thinking that client retries are probably a bad thing, though,
insofar as they are based on offsets into the resultset. At least for
Druid, it's not safe to assume a static dataset (new data could be
continuously being inserted) and so transparent simple
retry-and-skip-to-offset would lead to incorrect results.
In Phoenix do you use the Avatica client or did you write your own?
Gian
On Thu, May 25, 2017 at 3:28 PM, James Taylor <[email protected]>
wrote:
Current plan is to keep the load balancer with Phoenix, but that could
change if there's general interest. In the first cut, we weren't planning
on doing any client retries, but that's probably a good idea to add.
James
On Thu, May 25, 2017 at 1:28 PM, Gian Merlino <[email protected]> wrote:
I'm asking in the context of Druid, which also uses Avatica. Although it
sounds like PHOENIX-3654 means Phoenix is intending to go in the
direction
of client-side load balancing. Are you planning to contribute the work to
Avatica or keep it unique to Phoenix? We might want something similar in
Druid; client side load balancing will probably work better than using a
proxy, given how the servers don't share state at all.
If a backend server goes down, would a PHOENIX-3654 style client
transparently retry the query on a different server? Or would it fail and
expect the user to retry?
Gian
On Thu, May 25, 2017 at 12:55 PM, James Taylor <[email protected]>
wrote:
If you're using Avatica in the context of Phoenix, you might be
interested
in PHOENIX-3654 which is about adding a load balancer to the Phoenix
Query
Server.
Thanks,
James
On Thu, May 25, 2017 at 12:02 PM, Gian Merlino <[email protected]> wrote:
Is anyone out there using Avatica with servers (that don't share
connection
state) behind load balancers? Is that a workable configuration? I'm
guessing it might be if sticky sessions are enabled on the load
balancer.
What does the client do when the session switches to a new backend
server?
I found a blog post that talks about some of these issues in the
context
of
Phoenix:
https://community.hortonworks.com/articles/9377/deploying-
the-phoenix-query-server-in-production-e.html
It seems to suggest that the client will retry queries and skip to
the
most
recently read offset. Is that behavior on by default? This sounds
like
it
won't work for a database that is accepting new data -- the query
results
aren't generally going to be exact matches from run to run just due
to
new
rows being added. In that case, I'm struggling to think of any better
approach than failing the query and expecting the user to retry if
they
want to.
Gian
